home *** CD-ROM | disk | FTP | other *** search
/ PC World Interactive 1 / PC World Interactive 1 - Nisan 1997.iso / nostalji / bbs / faq / domain.txt < prev    next >
Internet Message Format  |  1995-08-10  |  99KB

  1. From: cdp@njit.edu (Chris Peckham)
  2. Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)
  3. Originator: cdp2582@hertz.njit.edu
  4. Keywords: BIND,DOMAIN,DNS
  5. Sender: news@njit.edu
  6. Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
  7. Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
  8. Date: Tue, 4 Jul 1995 04:17:24 GMT
  9. Approved: news-answers-request@MIT.EDU
  10. Expires: Tue 08 Aug 95 00:17:18 EDT
  11. Lines: 1338
  12.  
  13. Posted-By: auto-faq 3.1.1.2
  14. Archive-name: internet/tcp-ip/domains-faq/part1
  15. Revision: 1.6 1995/05/12 18:49:48
  16.  
  17.  
  18. This FAQ is edited and maintained by Chris Peckham, <cdp@njit.edu>. 
  19. The latest version may always be found for anonymous ftp from
  20.  
  21.     ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq
  22.     ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ
  23.  
  24. If you can contribute any answers for items in the TODO section, please do
  25. so by sending e-mail to domain-faq@njit.edu !  If you know of any items that 
  26. are not included and you feel that they should be,  send the relevant
  27. information to domain-faq@njit.edu.
  28.  
  29.  
  30. ------------------------------
  31.  
  32. Date: Fri May 12 14:41:47 EDT 1995
  33. Subject: Table of Contents
  34.  
  35. Table of Contents
  36. =================
  37. Part 1
  38. ------
  39.    0. TO DO
  40.    1. INTRODUCTION / MISCELLANEOUS
  41.       1.1  What is this newsgroup ?
  42.       1.2  More information
  43.       1.3  What is BIND and where is the latest version of BIND ?
  44.       1.4  How can I find the route between systems ?
  45.       1.5  Finding the hostname if you have the tcp-ip address
  46.       1.6  How to register a domain name
  47.       1.7  Change of Domain name
  48.       1.8  How memory and CPU does DNS use ?
  49.       1.9  Other things to consider when planning your servers  
  50.       1.10 Proper way to get NS and reverse IP records into DNS
  51.       1.11 How to get my address assign from NIC?
  52.       1.12 Is there a block of private IP addresses I can use?
  53.       1.13 Cache failed lookups
  54.       1.14 What does an NS record really do ?
  55.       1.15 DNS ports
  56.       1.16 Obtaining the latest cache file 
  57.    2. UTILITIES
  58.       2.1  Utilities to administer DNS zone files
  59.       2.2  DIG - Domain Internet Groper
  60.       2.3  DNS packet analyzer
  61.       2.4  host 
  62.       2.5  Programming with DNS
  63.       2.6  A source of information relating to DNS
  64.    3. DEFINITIONS
  65.       3.1  TCP/IP Host Naming Conventions
  66.       3.2  Slaves and servers with forwarders
  67.       3.3  When is a server authoritative?
  68.       3.4  Underscore in host-/domain names
  69.       3.5  Lame delegation
  70.       3.6  What does opt-class field do?
  71.       3.7  Top level domains
  72.       3.8  Classes of networks
  73.       3.9  What is CIDR ?
  74.       3.10 What is the rule for glue ?
  75.  
  76. Part 2
  77. ------
  78.    4. CONFIGURATION
  79.       4.1  Changing a Secondary server to a Primary
  80.       4.2  How do I subnet a Class B Address ?
  81.       4.3  Subnetted domain name service
  82.       4.4  Recommended format/style of DNS files
  83.       4.5  DNS on a system not connected to the Internet
  84.       4.6  Multiple Domain configuration
  85.       4.7  wildcard MX records
  86.       4.8  How to identify a wildcard MX record
  87.       4.9  Why are fully qualified domain names recommended ?
  88.       4.10 Distributing load using named
  89.       4.11 Order of returned records
  90.       4.12 resolv.conf 
  91.       4.13 Delegating authority 
  92.       4.14 DNS instead of NIS on a Sun OS 4.1.x system
  93.    5. PROBLEMS
  94.       5.1  No address for root server
  95.       5.2  Error - No Root Nameservers for Class XX
  96.       5.3  Bind 4.9.x and MX querying?
  97.       5.4  Some root nameservers don't know localhost
  98.       5.5  MX records and CNAMES and separate A records for MX targets
  99.       5.6  NS is a CNAME
  100.       5.7  Nameserver forgets own A record
  101.       5.8  General problems (core dumps !)
  102.       5.9  malloc and DECstations
  103.    6. ACKNOWLEDGEMENTS
  104.  
  105. ------------------------------
  106.  
  107. Date: Wed May  3 12:55:13 EDT 1995
  108. Subject: Q0 - TO DO list 
  109.  
  110.  
  111. * How to do an initial installation
  112. * How to change service providers (what happens)
  113. * Explain the difference between BIND (an implementation) and DNS (spec)
  114. * Expand the slave/forward section of Q 3.2
  115. * Add a definition of a "private domain" in discussion (or cut it out) 
  116. * mention mail-to-news gateways for newsgroup, mailing lists, anonymous
  117.   ftp, etc in what is newsgroup section
  118. * The evils of wildcard MX records
  119.  
  120.  
  121.  
  122. -------------------------------
  123.  
  124. Date: Thu Dec  1 11:08:28 EST 1994
  125. Subject: Q1.1 - What is this newsgroup ?
  126.  
  127. comp.protocols.tcp-ip.domains is the usenet newsgroup for discussion
  128. on issues relating to the Domain Name System (DNS).
  129.  
  130. This newsgroup is not for issues directly relating to IP routing and
  131. addressing.  Issues of that nature should be directed towards
  132. comp.protocols.tcp-ip.
  133.  
  134.  
  135. -------------------------------
  136.  
  137.  
  138. Date: Fri May 12 13:54:01 EDT 1995
  139. Subject: Q1.2 - More information
  140.  
  141.    You can find more information concerning DNS in the following places:
  142.  
  143.    * The BOG (BIND Operations Guide) - in the BIND distribution
  144.    * The FAQ included with bind4.9.3 doc/misc/FAQ
  145.    * DNS and BIND by Albitz and Liu (an O'Reilly & Associates Nutshell 
  146.      handbook)
  147.    * A number of RFCs (920, 974, 1032, 1034, 1101, 1123, 1178, 1183, 1348,
  148.                        1535, 1536, 1537, 1591, 1706, 1712, 1713)
  149.    * The DNS Resource Directory (DNSRD) 
  150.          http://www.dns.net/dnsrd
  151.    * If you are having troubles relating to sendmail and DNS, you may wish to
  152.      refer to the USEnet newsgroup comp.mail.sendmail and/or the FAQ for that
  153.      newsgroup
  154.          ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq
  155.    * Information concerning some frequently asked questions relating to
  156.      the Internet (i.e., what is the InterNIC, what is an RFC, what is the
  157.      IETF, etc) may be found for anonymous ftp from
  158.          ftp://ds.internic.net/fyi/fyi4.txt
  159.      A version may also be obtained with the URL
  160.          gopher://ds.internic.net/00/fyi/fyi4.txt 
  161.  
  162.  
  163. -------------------------------
  164.  
  165. Date: Fri Apr 28 13:42:09 EDT 1995
  166. Subject: Q1.3 - What is BIND and where is the latest version of BIND ?
  167.  
  168. Q: What is BIND ?
  169.  
  170. A: From the BOG Introduction -
  171.  
  172.         The Berkeley Internet Name Domain (BIND)  implements
  173.    an  Internet  name  server  for the BSD operating system.
  174.    The BIND consists of  a  server  (or  ``daemon'')  and  a
  175.    resolver  library.   A  name  server is a network service
  176.    that enables clients to name  resources  or  objects  and
  177.    share this information with other objects in the network.
  178.    This in effect is a  distributed  data  base  system  for
  179.    objects  in a computer network.  BIND is fully integrated
  180.    into BSD (4.3 and later releases)  network  programs  for
  181.    use  in  storing  and  retrieving host names and address.
  182.    The system administrator can configure the system to  use
  183.    BIND  as  a replacement to the older host table lookup of
  184.    information in the network hosts  file  /etc/hosts.   The
  185.    default configuration for BSD uses BIND.
  186.  
  187. Q: Where is the latest non-beta version of BIND ?
  188.  
  189. A: The latest non-beta version of BIND is version 4.9.2.  This can be
  190.    found for anonymous ftp from
  191.  
  192.          ftp://gatekeeper.dec.com/pub/misc/vixie/4.9.2-940221.tar.gz
  193.  
  194. Q: Where is the latest version of 4.9.3 located ?
  195.  
  196. A: You can reference this URL:
  197.  
  198.          http://www.isc.org/isc/
  199.  
  200.    At this time, the latest version of 4.9.3 may be found for anonymous ftp 
  201.    from
  202.  
  203.         ftp://ftp.vix.com/pri/vixie/bind-4.9.3-BETA17.tar.gz
  204.  
  205.         Size:           1532332 bytes
  206.         BSD checksum:   36044 1497
  207.         POSIX checksum: 3451112785 1532332
  208.         MD5 checksum:   604340af2eb7225819264c2ccf592bbd
  209.  
  210.      You won't be able to "ls" or "dir" the file.  You must "cd"
  211.      (inside of FTP) to the remote directory (/pri/vixie) unless you
  212.      plan to create a local /pri/vixie or unless you plan to give "get"
  213.      a second argument.  You can't ping this ftp server, ever.  To
  214.      retrieve this file, do this:
  215.  
  216.                 $ ftp ftp.vix.com
  217.                 user: anonymous
  218.                 password: (your e-mail address)
  219.                 ftp> cd /pri/vixie
  220.                 ftp> binary
  221.                 ftp> get bind-4.9.3-BETA17.tar.gz
  222.                 ftp> quit
  223.  
  224.    You will need GNU zip, Larry Wall's patch program (if there are any
  225.    patch files), and a C compiler to get BIND running from the above
  226.    mentioned source.
  227.  
  228.    GNU zip is available for anonymous ftp from
  229.  
  230.         ftp://prep.ai.mit.edu/pub/gnu/gzip-1.2.4.tar
  231.  
  232.    patch is available for anonymous ftp from
  233.  
  234.         ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz
  235.  
  236. ------------------------------
  237.  
  238. Date: Mon Jan  2 13:27:27 EST 1995
  239. Subject: Q1.4 - How can I find the route between systems
  240.  
  241. Q: How can I find the path taken by packets between two systems/domains ?
  242.  
  243. A: Get the source of the 'traceroute' command, compile it and install
  244.    it on your system.  
  245.  
  246.    One version of this program with additional functionality may be found
  247.    for anonymous ftp from
  248.  
  249.        ftp://ftp.nikhef.nl/pub/network/traceroute.tar.Z
  250.  
  251.    This package is mirrored at
  252.  
  253.        ftp://ftp.njit.edu/pub/dns/nikhef/traceroute.tar.Z 
  254.  
  255.    Another version may be found for anonymous ftp from
  256.  
  257.        ftp://ftp.psc.edu/pub/net_tools/traceroute.tar
  258.  
  259.  
  260. ------------------------------
  261.  
  262. Date: Thu Dec  1 09:55:24 EST 1994
  263. Subject: Q1.5 - Finding the hostname if you have the tcp-ip address
  264.  
  265. Q: Can someone tell me how can I find the name of the domain if I know the
  266.    tcp-ip address of the domain? Is there some kind of service for this?
  267.  
  268. A: For an address a.b.c.d you can always do:
  269.  
  270. % nslookup
  271. > set q=ptr
  272. > d.c.b.a.in-addr.arpa.
  273.  
  274.    Most newer version of nslookup (since 4.8.3) will recognize an address, 
  275.    so you can just say:
  276.  
  277. % nslookup a.b.c.d
  278.  
  279.    DiG will work like this also:
  280.  
  281. $ dig -x a.b.c.d
  282.  
  283.    Host from the contrib/host from the bind distribution may also be used.
  284.  
  285. -------------------------------
  286.  
  287. Date: Fri Apr 28 13:16:32 EDT 1995
  288. Subject: Q1.6 - How to register a domain name
  289.  
  290. Q: I would like to register a domain.  How do I do this ?   Can a name be
  291.    reserved, or must we already have an IP address and be hooked up to the
  292.    Internet before obtaining a domain name?
  293.  
  294. A: You can talk to your Internet Service Provider (ISP).  They can submit 
  295.    the registration for you.  If you are not going to be directly
  296.    connected, they should be able to offer MX records for your domain
  297.    for mail delivery (so that mail sent to the new domain will be sent
  298.    to your "standard" account).   In the case where the registration is
  299.    done by the organization itself, it still makes the whole process
  300.    much easier if the ISP is approached for secondary servers _before_
  301.    the InterNIC is approached for registration.
  302.  
  303.    For information about making the registration yourself, look to the
  304.    InterNIC !
  305.  
  306.         ftp://internic.net/templates/ 
  307.         gopher://rs.internic.net/
  308.         http://www.internic.net/infoguide.html
  309.         http://www.ripe.net
  310.  
  311.    You will need at least two domain name servers when you register your 
  312.    domain.  Many ISP's are willing to provide primary and/or secondary name 
  313.    service for their customers.
  314.  
  315.    Many times, registration of a domain name can be initiated by sending 
  316.    e-mail to the zone contact. You can obtain the contact in the 
  317.    SOA record for the country, or in a whois server:
  318.  
  319.          $ nslookup -type=SOA fr.
  320.          origin = ns1.nic.fr
  321.          mail addr = nic.nic.fr
  322.          ...
  323.  
  324.    The mail address to contact in this case is 'nic@nic.fr' (you must 
  325.    substitute an '@' for the first dot in the mail addr field).
  326.  
  327.    An alternate method to obtain the e-mail address of the national NIC
  328.    is the 'whois' server at InterNIC.   
  329.  
  330.    You may be requested to make your request to another email address or
  331.    using a certain information template/application.
  332.  
  333.  
  334. -------------------------------
  335.  
  336. Date: Sun Nov 27 23:32:41 EST 1994
  337. Subject: Q1.7 - Change of Domain name
  338.  
  339. Q: We are preparing for a change of our domain name:
  340.         abc.foobar.com -> foobar.net
  341.  
  342.    What are the tricks and caveats we should be aware of ?
  343.  
  344. A: The forward zones are easy and there are a number of ways to do it.  
  345.    One way is the following:
  346.  
  347.    Have a single db file for the 2 domains, and have a single machine
  348.    be the primary server for both abc.foobar.com and foobar.net.
  349.  
  350.    To resolve the host foo in both domains, use a single zone file which
  351.    merely uses this for the host:
  352.  
  353. foo             IN      A       1.2.3.4
  354.  
  355.    Use a "@" wherever the domain would be used ie for the SOA:
  356.  
  357. @               IN      SOA     (...
  358.  
  359.    Then use this pair of lines in your named.boot:
  360.  
  361. primary         abc.foobar.com  db.foobar
  362. primary         foobar.net      db.foobar
  363.  
  364.    The reverse zones should either contain PTRs to both names,
  365.    or to whichever name you believe to be canonical currently.
  366.  
  367. -------------------------------
  368.  
  369. Date: Fri Apr 28 13:52:20 EDT 1995
  370. Subject: Q1.8 - How memory and CPU does DNS use ?
  371.  
  372. Q: How much memory and CPU does DNS use ?
  373.  
  374. A: It can use quite a bit !  The main thing that BIND needs is memory.  
  375.    It uses very little CPU or network bandwidth.   The main 
  376.    considerations to keep in mind when planning are:
  377.  
  378.         1) How many zones do you have and how large are they ?
  379.         2) How many clients do you expect to serve and how active are they ?
  380.  
  381.    As an example, here is a snapshot of memory usage from CSIRO Division 
  382.    of Mathematics and Statistics, Australia
  383.  
  384.       Named takes several days to stabalize its memory usage.
  385.  
  386.       Our main server stabalises at ~10Mb. It takes about 3 days to
  387.       reach this size from 6 M at startup. This is under Sun OS 4.1.3U1.
  388.  
  389.    As another example, here is the configuration of ns.uu.net (from late 
  390.    1994):
  391.  
  392.       ns.uu.net only does nameservice.  It is running a version of BIND
  393.       4.9.3 on a Sun Classic with 96 MB of RAM, 220 MB of swap (remember
  394.       that Sun OS will reserve swap for each fork, even if it is not needed)
  395.       running Sun OS 4.1.3_U1.
  396.  
  397.       Joseph Malcolm, of Alternet, states that named generally hovers at 
  398.       5-10% of the CPU, except after a reload, when it eats it all.  He 
  399.       also states that if you are interested in the network connectivity 
  400.       around the system (ns.uu.net is located off of Falls-Church4), a 
  401.       PostScript map is available for anonymous ftp from
  402.  
  403.          ftp://ftp.uu.net/uunet-info/alternet.map.ps
  404.  
  405.  
  406. -------------------------------
  407.  
  408. Date: Mon Jan  2 14:24:51 EST 1995
  409. Subject: Q1.9 - Other things to consider when planning your servers  
  410.  
  411.   When making the plans to set up your servers, you may want to also 
  412.   consider the following issues:
  413.  
  414.         A) Server O/S limitations/capacities (which tend to be widely
  415.            divergent from vendor to vendor)
  416.         B) Client resolver behavior (even more widely divergent)
  417.         C) Expected query response time
  418.         D) Redundancy
  419.         E) Desired speed of change propagation
  420.         F) Network bandwidth availability
  421.         G) Number of zones/subdomain-levels desired
  422.         H) Richness of data stored (redundant MX records? HINFO records?)
  423.         I) Ease of administration desired
  424.         J) Network topology (impacts reverse-zone volume)
  425.  
  426.   Assuming a best-possible case for the factors above, particularly (A), (B),
  427.   (C), (F), (G) & (H), it would be possible to run a 1000-node domain
  428.   using a single lowly 25 or 40 MHz 386 PC with a fairly modest amount of RAM 
  429.   by today's standards, e.g. 4 or 8 Meg.   However, this configuration would 
  430.   be slow, unreliable, and would provide no functionality beyond your basic 
  431.   address-to-name and name-to-address mappings.
  432.  
  433.   Beyond that baseline case, depending on what factors listed above,
  434.   you may want look at other strategies, such splitting up the DNS
  435.   traffic among several machines strategically located, possibly larger ones,
  436.   and/or subdividing your domain itself. There are many options, tradeoffs, 
  437.   and DNS architectural paradigms from which to choose.
  438.  
  439.  
  440. ------------------------------
  441.  
  442. Date: Mon Jan  2 13:03:53 EST 1995
  443. Subject: Q1.10 - Proper way to get NS and reverse IP records into DNS
  444.  
  445.  
  446. Q: Reverse domain registration is separate from forward domain registration.
  447.    How do I get it updated ?
  448.  
  449. A: Blocks of network addresses have been delegated by the InterNIC.  Check
  450.    if your network a.b.c.0 is in such a block by using nslookup:
  451.  
  452.    nslookup -type=soa c.b.a.in-addr.arpa.
  453.    nslookup -type=soa b.a.in-addr.arpa.
  454.    nslookup -type=soa a.in-addr.arpa.
  455.  
  456.    One of the above should give you the information you are looking for
  457.    (the others will return with an error something like `*** No start of
  458.    authority (SOA) records available for ...')
  459.    This will give you the email address of the person to whom you should
  460.    address your change request.
  461.  
  462.    If none of these works, your network probably has not been delegated
  463.    by the InterNIC and you need to contact them directly.
  464.  
  465.    CIDR has meant that the registration is delegated, but registration
  466.    of in-addr.arpa has always been separate from forward zones - and
  467.    for good reason - in that the forward and reverse zones may have
  468.    different policies, contents etc, may be served by a different set
  469.    of nameservers, and exist at different times (usually only at point
  470.    of creation).  There isn't a one-to-one mapping between the two, so
  471.    merging the registration would probably cause more problems than
  472.    people forgetting/not-knowing that they had to register in-addr.arpa
  473.    zones separately.  For example, there are organizations that have
  474.    hundreds of networks and two or more domains, with a sprinkling of
  475.    machines from each network in each of the domains.
  476.  
  477.  
  478. -------------------------------
  479.  
  480. Date: Mon Jan  2 13:08:38 EST 1995
  481. Subject: Q1.11 - How to get my address assign from NIC ?
  482.  
  483.  
  484. Q: Can anyone tell me how can I get the address from NIC?  How many subnets
  485.    will NIC give to me?
  486.  
  487. A: You should probably ask your Internet provider to give you an address.
  488.    These days, addresses are being distributed through the providers,
  489.    so that they can assign adjacent blocks of addresses to sites that
  490.    go through the same provider, to permit more efficient routing on
  491.    the backbones.
  492.  
  493.    Unless you have thousands of hosts, you probably won't be able to get a
  494.    class B these days.  Instead, you can get a series of class C networks.
  495.    Large requests will be queried, so be ready to provide a network plan if
  496.    you ask for more than 16 class C networks.
  497.  
  498.    If you can't do this through your Internet provider, you can look for a
  499.    subnet registration form on rs.internic.net.  See the answer in this FAQ
  500.    to the question "How to register a domain name" for a URL to these
  501.    forms.
  502.  
  503. -------------------------------
  504.  
  505. Date: Mon Jan  2 13:12:01 EST 1995
  506. Subject: Q1.12 -Is there a block of private IP addresses I can use?
  507.  
  508.  
  509. Q: Is there a block of private IP addresses I can use?
  510.  
  511. A: This answer may be found in the FAQ for the newsgroup comp.dcom.sys.cisco
  512.    available for anonymous ftp from
  513.  
  514.         ftp://rtfm.mit.edu/pub/usenet/comp.dcom.sys.cisco
  515.  
  516.    There is a block of private IP addresses that you can use.  However 
  517.    whether you wish to do so is an issue of some debate.
  518.  
  519.    There are two RFCs which discuss this issue, and present opposing
  520.    views:
  521.  
  522. 1597 Address Allocation for Private Internets. Y. Rekhter, B.
  523.      Moskowitz, D. Karrenberg & G. de Groot. March 1994. (Format:
  524.      TXT=17430 bytes)
  525.  
  526. 1627 Network 10 Considered Harmful (Some Practices Shouldn't be
  527.      Codified). E. Lear, E. Fair, D. Crocker & T. Kessler. June 1994.
  528.      (Format: TXT=18823 bytes)
  529.  
  530.    Neither one of these RFCs is anything more than a set of informational
  531.    guidelines; they are *not* words to live by (remember that RFC stands
  532.    for Request For Comments). If you're seriously considering using
  533.    private IP addresses, please read them both.
  534.  
  535.    In any event, RFC 1597 documents the allocation of the following
  536.    addresses for use by ``private internets'':
  537.  
  538.         10.0.0.0        -   10.255.255.255
  539.         172.16.0.0      -   172.31.255.255
  540.         192.168.0.0     -   192.168.255.255
  541.  
  542.    Most importantly, it is vital that nothing using these addresses
  543.    should ever connect to the global Internet, or have plans to do so.
  544.    Please read the above RFCs before considering implementing such
  545.    a policy.
  546.  
  547.  
  548. -------------------------------
  549.  
  550. Date: Mon Jan  2 13:55:50 EST 1995
  551. Subject: Q1.13 - Cache failed lookups
  552.  
  553. Q: Does BIND cache negative answers (failed DNS lookups) ?
  554.  
  555. A: Yes, BIND 4.9.3 will cache negative answers.
  556.  
  557.  
  558. -------------------------------
  559.  
  560. Date: Fri Feb 10 15:35:07 EST 1995
  561. Subject: Q1.14 - What does an NS record really do ?
  562.  
  563. Q: What does a NS record really do ?
  564.  
  565. A: The NS records in your zone data file pointing to the zone's name 
  566.    servers (as opposed to the servers of delegated subdomains) don't do 
  567.    much.  They're essentially unused, though they are returned in the 
  568.    authority section of reply packets from your name servers.
  569.  
  570. -------------------------------
  571.  
  572. Date: Fri Feb 10 15:40:10 EST 1995
  573. Subject: Q1.15 - DNS ports
  574.  
  575. Q: Does anyone out there have any information/experience on exactly which 
  576.    TCP/UDP ports DNS uses to send and receive queries ?
  577.  
  578. A: Use the following chart:
  579.  
  580.    Prot Src   Dst   Use
  581.    udp  53    53    Queries between servers (eg, recursive queries)
  582.                     Replies to above
  583.    tcp  53    53    Queries with long replies between servers, zone 
  584.                     transfers Replies to above
  585.    udp  >1023 53    Client queries (sendmail, nslookup, etc ...)
  586.    udp  53    >1023 Replies to above
  587.    tcp  >1023 53    Client queries with long replies
  588.    tcp  53    >1023 Replies to above
  589.  
  590.    Note: >1023 is for non-priv ports on Un*x clients. On other client 
  591.          types, the limit may be more or less.
  592.  
  593.    Another point to keep in mind when designing filters for DNS is that a
  594.    DNS server uses port 53 both as the source and destination for it's
  595.    queries.  So, a client queries an initial server from an unreserved
  596.    port number to UDP port 53.  If the server needs to query another
  597.    server to get the required info, it sends a UDP query to that server
  598.    with both source and destination ports set to 53.  The response is then
  599.    sent with the same src=53 dest=53 to the first server which then
  600.    responds to the original client from port 53 to the original source
  601.    port number.
  602.  
  603.    The point of all this is that putting in filters to only allow UDP
  604.    between a high port and port 53 will not work correctly, you must also
  605.    allow the port 53 to port 53 UDP to get through.
  606.  
  607.    Also, ALL versions of BIND use TCP for queries in some cases.  The
  608.    original query is tried using UDP.  If the response is longer than
  609.    the allocated buffer, the resolver will retry the query using a TCP
  610.    connection.  If you block access to TCP port 53 as suggested above,
  611.    you may find that some things don't work.
  612.  
  613.    Newer version of BIND allow you to configure a list of IP addresses
  614.    from which to allow zone transfers.  This mechanism can be used to
  615.    prevent people from outside downloading your entire namespace.
  616.  
  617.  
  618. -------------------------------
  619.  
  620.  
  621. Date: Fri Apr 28 14:19:10 EDT 1995
  622. Subject: Q1.16 - Obtaining the latest cache file
  623.  
  624. Q: What is the cache file and where can I obtain the latest version ? 
  625.  
  626. A: From the "Name Server Operations Guide"
  627.  
  628.       6.3.  Cache Initialization
  629.  
  630.          6.3.1.  root.cache
  631.  
  632.                  The name server needs to know the servers that
  633.             are  the  authoritative  name  servers for the root
  634.             domain of the network.  To do this we have to prime
  635.             the name server's cache with the addresses of these
  636.             higher authorities.  The location of this  file  is
  637.             specified  in  the  boot  file. ...
  638.  
  639.    A copy of the comments in the file available from the InterNIC follow:
  640.  
  641.       ;       This file holds the information on root name servers needed to
  642.       ;       initialize cache of Internet domain name servers 
  643.       ;       (e.g. reference this file in the "cache  .  <file>"
  644.       ;       configuration file of BIND domain name servers).
  645.       ;
  646.       ;       This file is made available by InterNIC registration services
  647.       ;       under anonymous FTP as
  648.       ;           file                /domain/named.root
  649.       ;           on server           FTP.RS.INTERNIC.NET
  650.       ;       -OR- under Gopher at    RS.INTERNIC.NET
  651.       ;           under menu          InterNIC Registration Services (NSI)
  652.       ;              submenu          InterNIC Registration Archives
  653.       ;           file                named.root
  654.       ;
  655.       ;       last update:    Oct 5, 1994
  656.       ;       related version of root zone:   1994100500
  657.       ;
  658.  
  659.    If you have a version of dig running, you may obtain the information with
  660.    the command
  661.  
  662.       dig @ns.internic.net . ns
  663.  
  664.  
  665. -------------------------------
  666.  
  667.  
  668. Date: Mon Jan  2 13:13:49 EST 1995
  669. Subject: Q2.1 - Utilities to administer DNS zone files
  670.  
  671. Q: I am wondering if there are utilities available to ease the 
  672.    administration of the zone files in the DNS.
  673.  
  674. A: There are a few.  Two common ones are h2n and makezones.  Both are perl
  675.    scripts.  h2n is used to convert host tables into zone data files.  It 
  676.    is available for anonymous ftp from 
  677.  
  678.    ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z.
  679.  
  680.    makezones works from a single file that looks like a forward zone file,
  681.    with some additional syntax for special cases.  It is included in the 
  682.    current BIND distribution.  The newest version is always available for 
  683.    anonymous ftp from
  684.  
  685.    ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones
  686.    
  687.    This package is mirrored at
  688.  
  689.    ftp://ftp.njit.edu/pub/dns/cus.cam.ac/makezones
  690.  
  691.    More information may be found using the DNS Resource Directory
  692.  
  693.    http://www.dns.net/dnsrd
  694.  
  695.  
  696. -------------------------------
  697.  
  698. Date: Thu Dec  1 11:09:11 EST 1994
  699. Subject: Q2.2 - DIG - Domain Internet Groper
  700.  
  701. Q: Where can I find the latest version of DIG ?
  702.  
  703. A: The latest and greatest, official, accept-no-substitutes version of DiG
  704.    is the one that comes with BIND.  Get the latest kit.
  705.  
  706. -------------------------------
  707.  
  708. Date: Mon May 15 12:57:42 EDT 1995
  709. Subject: Q2.3 -DNS packet analyser
  710.  
  711. Q: I'm looking for a Ethernet packet analyser of public domain or standard
  712.    (like tcpdump, snoop, packetman) that is able to determine DNS data
  713.    field protocol
  714.  
  715. A: There is a free ethernet analyser called Ethload available for PC's 
  716.    running DOS. The latest filename is ETHLD104.ZIP. It understands lots 
  717.    of protocols including TCP/UDP. It'll look inside there and display 
  718.    DNS/BOOTP/ICMP packets etc. (Ed. note: something nice for someone to
  719.    add to tcpdump ;^) ).  Depending on the ethernet controller it's given 
  720.    it'll perform slightly differently. It handles NDIS/Novell/Packet 
  721.    drivers.  It works best with Novell's promiscuous mode drivers.  
  722.    A A SimTel mirror site should have the program available for anonymous
  723.    ftp.  As an example,
  724.  
  725.       ftp://oak.oakland.edu/SimTel/msdos/lan/ethld104.zip
  726.  
  727.  
  728. -------------------------------
  729.  
  730. Date: Sun Dec  4 21:15:38 EST 1994
  731. Subject: Q2.4 - host
  732.  
  733. A section from the host man page:
  734.  
  735.      host looks for information about Internet hosts and domain
  736.      names.  It gets this information from a set of intercon-
  737.      nected servers that are spread across the world. The infor-
  738.      mation is stored in the form of "resource records" belonging
  739.      to hierarchically organized "zones".
  740.  
  741.      By default, the program simply converts between host names
  742.      and Internet addresses. However, with the -t, -a and -v
  743.      options, it can be used to find all of the information about
  744.      domain names that is maintained by the domain nameserver
  745.      system.  The information printed consists of various fields
  746.      of the associated resource records that were retrieved.
  747.  
  748.      The arguments can be either host names (domain names) or
  749.      numeric Internet addresses.
  750.  
  751. 'host' is compatible with both BIND 4.9 and BIND 4.8
  752.  
  753. 'host' may be found in contrib/host in the BIND distribution.  The latest
  754. version always available for anonymous ftp from
  755.  
  756.     ftp://ftp.nikhef.nl/pub/network/host.tar.Z
  757.  
  758. It may also be found for anonymous ftp from
  759.  
  760.     ftp://ftp.uu.net/networking/ip/dns/host.tar.Z
  761.  
  762. -------------------------------
  763.  
  764. Date: Fri Feb 10 15:25:11 EST 1995
  765. Subject: Q2.5 - Programming with DNS
  766.  
  767. Q:  How can I use DNS information in my program?
  768.  
  769. A:  It depends on precisely what you want to do:
  770.  
  771.     a) Consider whether you need to write a program at all.  It may well 
  772.        be easier to write a shell program (e.g. using awk or perl) to parse 
  773.        the output of dig, host or nslookup.
  774.  
  775.     b) If all you need is names and addresses, there will probably be 
  776.        system routines 'gethostbyname' and 'gethostbyaddr' to provide this
  777.        information.
  778.  
  779.     c) If you need more details, then there are system routines (res_query 
  780.        and res_search) to assist with making and sending DNS queries.  
  781.        However, these do not include a routine to parse the resulting answer 
  782.        (although routines to assist in this task are provided).  There is a 
  783.        separate library available that will take a DNS response and unpick 
  784.        it into its constituent parts, returning a C structure that can be 
  785.        used by the program.  The source for this library is available for
  786.        anonymous ftp from
  787.  
  788.             ftp://hpux.csc.liv.ac.uk/hpux/Networking/Admin/resparse-*
  789.  
  790.  
  791. -------------------------------
  792.  
  793.  
  794. Date: Wed May  3 12:46:50 EDT 1995
  795. Subject: Q2.6 - A source of information relating to DNS
  796.  
  797. Q: Where can I find utilities and tools to help me manage my zone files ?
  798.  
  799. A: There are several tools available.  Please refer to the "tools" section
  800.    of the DNS resources directory:
  801.  
  802.       http://www.dns.net/dnsrd/tools.html
  803.  
  804.  
  805. -------------------------------
  806.  
  807.  
  808. Date: Fri May 12 14:33:40 EDT 1995
  809. Subject: Q3.1 - TCP/IP Host Naming Conventions
  810.  
  811. Q: Is a guide available relating to naming systems ?
  812.  
  813. A: One guide/resource is RFC 1178, "Choosing a Name for Your Computer", 
  814.    which is available via anonymous FTP from 
  815.  
  816.          ftp://ftp.internic.netrfc/rfc1178.txt
  817.  
  818.    RFCs (Request For Comments) are specifications and guidelines for how
  819.    many aspects of TCP/IP and the Internet (should) work.  Most RFCs are
  820.    fairly technical documents, and some have semantics that are hotly
  821.    contested in the newsgroups.  But a few, like RFC 1178, are actually
  822.    good to read for someone who's just starting along a TCP/IP path.
  823.  
  824.  
  825. -------------------------------
  826.  
  827. Date: Thu Dec  1 10:32:43 EST 1994
  828. Subject: Q3.2 - What are slaves and forwarders ?
  829.  
  830. Q: What are slaves and forwarders ?
  831.  
  832. A: "forwarders" is a list of NS records that are _prepended_ to a list
  833.    of NS records to query if the data is not available locally.  This
  834.    allows a rich cache of records to be built up at a centralized
  835.    location.  This is good for sites that have sporadic or very slow
  836.    connections to the Internet.  (demand dial-up, for example)  It's
  837.    also just a good idea for very large distributed sites to increase
  838.    the chance that you don't have to go off to the Internet to get an
  839.    IP address. (sometimes for addresses across the street!)
  840.  
  841.    "slave" modifies this to say to replace the list of NS records
  842.    with the forwarders entry, instead of prepending to it.  This is
  843.    for firewalled environments, where the nameserver can't directly
  844.    get out to the Internet at all.
  845.  
  846.    "slave" is meaningless (and invalid, in late-model BINDs) without
  847.    "forwarders".  "forwarders" is an entry in named.boot, and therefore
  848.    applies only to the nameserver (not to resolvers).
  849.  
  850. -------------------------------
  851.  
  852. Date: Mon Jan  2 13:15:13 EST 1995
  853. Subject: Q3.3 - When is a server authoritative?
  854.  
  855.  
  856. Q: What criteria does a server use to determine if it is authoritative
  857.    for a domain?  
  858.  
  859. A: In the case of BIND:
  860.         1) The server contains current data in files for the zone in 
  861.            question (Data must be current for secondaries, as defined 
  862.            in the SOA)
  863.         2) The server is told that it is authoritative for the zone, by
  864.            a 'primary' or 'secondary' keyword in /etc/named.boot.
  865.         3) The server does an error-free load of the zone.
  866.  
  867. Q: I have set up a DNS where there is an SOA record for
  868.    the domain, but the server still does not consider itself
  869.    authoritative.  (I used nslookup and set server=the correct machine.)
  870.    It seems to me that something is not matching up somewhere.  I suspect
  871.    that this is because the service provider has not given us control
  872.    over the IP numbers in our own domain, and so while the machine listed
  873.    has an A record for an address, there is no corresponding PTR record.
  874.  
  875. A: That's possible too, but is unrelated to the first question.
  876.    You need to be delegated a zone before outside people will start
  877.    talking to your server.  However, a server can still be authoritative
  878.    for a zone even though it hasn't been delegated authority (it's just 
  879.    that only the people who use that as their server will see the data).
  880.     
  881.    A server may consider itself non-authoritative even though it's a
  882.    primary if there is a syntax error in the zone (see point 3 above).
  883.  
  884. Q: I always believe that it was the NS record that defined authoritative
  885.    servers.
  886.  
  887. A: Nope, delegation is a separate issue from authoritativeness.  
  888.    You can still be authoritative, but not delegated.  (you can also be 
  889.    delegated, but not authoritative -- that's a "lame delegation")
  890.  
  891. Q: We have had problems in the past from servers that were
  892.    authoritative (primary or secondary) but no NS, so other thought they
  893.    were not.  Some resolvers get very confused when they get non-
  894.    authoritative data from the primary server.
  895.  
  896. A: Yes, that's a lame delegation.  That's not caused by what you said,
  897.    but rather by a server which is _not_ authoritative for a zone, yet
  898.    someone else (the parent) is saying that a server is authoritative
  899.    (via the NS records).
  900.  
  901.    The set of NS records in the parent zone must be a subset of the
  902.    authoritative servers to avoid lame delegations.
  903.  
  904.  
  905. -------------------------------
  906.  
  907. Date: Fri Apr 28 13:26:37 EDT 1995
  908. Subject: Q3.4 - underscore in host-/domainnames
  909.  
  910.  
  911. Q: I had a quick look on whether underscores are allowed in host- or 
  912.    domainnames.
  913.  
  914.         RFC 1033 allows them.
  915.         RFC 1035 doesn't.
  916.         RFC 1123 doesn't.
  917.         dnswalk complains about them.
  918.  
  919.    Which RFC is the final authority these days?
  920.  
  921. A: Actually RFC 1035 deals with names of machines or names of
  922.    mail domains. i.e "_" is not permitted in a hostname or on the
  923.    RHS of the "@" in local@domain.
  924.  
  925.    Underscore is permitted where ever the domain is NOT one of
  926.    these types of addresses.
  927.  
  928.    In general the DNS mostly contains hostnames and mail domainnames.
  929.    This will change as new resource record types for authenticating DNS 
  930.    queries start to appear.
  931.  
  932.    The latest version of 'host' checks for illegal characters in A/MX
  933.    record names and the NS/MX target names.
  934.  
  935.    After saying all of that, remember that RFC 1123 is a Required Internet 
  936.    Standard (per RFC 1720), and RFC 1033 isn't.  Even 1035 isn't a required 
  937.    standard.  Therefore, RFC 1123 wins, no contest.
  938.  
  939.  
  940. -------------------------------
  941.  
  942. Date: Fri Dec  2 15:03:56 EST 1994
  943. Subject: Q3.5 - Lame delegation
  944.  
  945. Q: What is lame delegation ?
  946.  
  947. A: Two things are required for a lame delegation:
  948.         1) A nameserver X is delegated as authoritative for a zone.
  949.         2) Nameserver X is not performing nameservice for that zone.
  950.  
  951.    Try to think of a lame delegation as a long-term condition, brought
  952.    about by a misconfiguration somewhere.  Bryan Beecher's 1992 LISA
  953.    paper on lame delegations is good to read on this.  The problem
  954.    really lies in misconfigured nameservers, not "lameness" brought
  955.    about by transient outages.  The latter is common on the Internet
  956.    and hard to avoid, while the former is correctable.
  957.  
  958.    In order to be performing nameservice for a zone, it must have
  959.    (presumed correct) data for that zone, and it must be answering
  960.    authoritatively to resolver queries for that zone.  (The AA bit is
  961.    set in the flags section)
  962.  
  963.    The "classic" lame delegation case is when nameserver X is delegated
  964.    as authoritative for domain Y, yet when you ask Y about X, it
  965.    returns non-authoritative data.
  966.  
  967.    Here's an example that shows what happens most often (using dig,
  968.    dnswalk, and doc to find).
  969.  
  970.    Let's say the domain bogus.com gets registered at the NIC and they
  971.    have listed 2 primary name servers, both from their *upstream*
  972.    provider:
  973.  
  974.  bogus.com      IN      NS      ns.bogus.com
  975.  bogus.com      IN      NS      upstream.com
  976.  bogus.com      IN      NS      upstream1.com
  977.  
  978.    So the root servers have this info.  But when the admins at
  979.    bogus.com actually set up their zone files they put something like:
  980.  
  981.  bogus.com      IN      NS      upstream.com
  982.  bogus.com      IN      NS      upstream1.com
  983.  
  984.    So your name server may have the nameserver info cached (which it
  985.    may have gotten from the root).  The root says "go ask ns.bogus.com"
  986.    since they are authoritative
  987.  
  988.    This is usually from stuff being registered at the NIC (either
  989.    nic.ddn.mil or rs.internic.net), and then updated later, but the
  990.    folks who make the updates later never let the folks at the NIC know
  991.    about it.
  992.  
  993. Q: How can I see if the server is "lame" ?
  994.  
  995. A: Go to the authoritative servers one level up, and ask them who
  996.    they think is authoritative, and then go ask each one of those
  997.    delegees if they think that they themselves are authoritative.  If any
  998.    responds "no", then you know who the lame delegation is, and who is
  999.    delegating lamely to them.  You can then send off a message to the
  1000.    administrators of the level above.
  1001.  
  1002.    The 'lamers' script from Byran Beecher really takes care of all this
  1003.    for you.  It parses the lame delegation notices from BIND's syslog
  1004.    and summarizes them for you.  It may be found in the contrib section
  1005.    of the latest BIND distribution.  The latest version is available
  1006.    for anonymous ftp from
  1007.  
  1008.        ftp://terminator.cc.umich.edu/dns/lame-delegations/
  1009.  
  1010.    If you want to actively check for lame delegations, you can use 'doc'
  1011.    and 'dnswalk'.   You can check things manually with 'dig'.
  1012.  
  1013. -------------------------------
  1014.  
  1015. Date: Thu Dec  1 11:10:39 EST 1994
  1016. Subject: Q3.6 - What does opt-class field do?
  1017.  
  1018. Q: Just something I was wondering about: What does the opt-class
  1019.    field in an name database do (the one that always says IN)?
  1020.    What would happen if I put something else there instead?
  1021.  
  1022. A: This field is the address class.  From the BOG -
  1023.  
  1024.       ...is the address class; currently, only one class
  1025.       is supported: IN  for  internet  addresses  and  other
  1026.       internet information.  Limited support is included for
  1027.       the HS  class,  which  is  for  MIT/Athena  ``Hesiod''
  1028.       information.
  1029.  
  1030. -------------------------------
  1031.  
  1032. Date: Fri Feb 10 14:49:54 EST 1995
  1033. Subject: Q3.7 - Top level domains
  1034.  
  1035.  
  1036. A section from RFC 1591:
  1037.  
  1038.    2.  The Top Level Structure of the Domain Names
  1039.  
  1040.    In the Domain Name System (DNS) naming of computers there is a
  1041.    hierarchy of names.  The root of system is unnamed.  There are a set
  1042.    of what are called "top-level domain names" (TLDs).  These are the
  1043.    generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
  1044.    letter country codes from ISO-3166.  It is extremely unlikely that
  1045.    any other TLDs will be created.
  1046.  
  1047. [ Ed note:  the ISO-3166 country codes may be found for anonymous ftp from:
  1048.  
  1049.      ftp://ftp.isi.edu/in-notes/iana/assignments/country-codes
  1050.      ftp://ftp.ripe.net/iso3166-codes
  1051. ]
  1052.  
  1053.    Under each TLD may be created a hierarchy of names.  Generally, under
  1054.    the generic TLDs the structure is very flat.  That is, many
  1055.    organizations are registered directly under the TLD, and any further
  1056.    structure is up to the individual organizations.
  1057.  
  1058.    In the country TLDs, there is a wide variation in the structure, in
  1059.    some countries the structure is very flat, in others there is
  1060.    substantial structural organization.  In some country domains the
  1061.    second levels are generic categories (such as, AC, CO, GO, and RE),
  1062.    in others they are based on political geography, and in still others,
  1063.    organization names are listed directly under the country code.  The
  1064.    organization for the US country domain is described in RFC 1480.
  1065.  
  1066.    Each of the generic TLDs was created for a general category of
  1067.    organizations.  The country code domains (for example, FR, NL, KR,
  1068.    US) are each organized by an administrator for that country.  These
  1069.    administrators may further delegate the management of portions of the
  1070.    naming tree.  These administrators are performing a public service on
  1071.    behalf of the Internet community.  Descriptions of the generic
  1072.    domains and the US country domain follow.
  1073.  
  1074.    Of these generic domains, five are international in nature, and two
  1075.    are restricted to use by entities in the United States.
  1076.  
  1077.    World Wide Generic Domains:
  1078.  
  1079.    COM - This domain is intended for commercial entities, that is
  1080.          companies.  This domain has grown very large and there is
  1081.          concern about the administrative load and system performance if
  1082.          the current growth pattern is continued.  Consideration is
  1083.          being taken to subdivide the COM domain and only allow future
  1084.          commercial registrations in the subdomains.
  1085.  
  1086.    EDU - This domain was originally intended for all educational
  1087.          institutions.  Many Universities, colleges, schools,
  1088.          educational service organizations, and educational consortia
  1089.          have registered here.  More recently a decision has been taken
  1090.          to limit further registrations to 4 year colleges and
  1091.          universities.  Schools and 2-year colleges will be registered
  1092.          in the country domains (see US Domain, especially K12 and CC,
  1093.          below).
  1094.  
  1095.    NET - This domain is intended to hold only the computers of network
  1096.          providers, that is the NIC and NOC computers, the
  1097.          administrative computers, and the network node computers.  The
  1098.          customers of the network provider would have domain names of
  1099.          their own (not in the NET TLD).
  1100.  
  1101.    ORG - This domain is intended as the miscellaneous TLD for
  1102.          organizations that didn't fit anywhere else.  Some non-
  1103.          government organizations may fit here.
  1104.  
  1105.    INT - This domain is for organizations established by international
  1106.          treaties, or international databases.
  1107.  
  1108.    United States Only Generic Domains:
  1109.  
  1110.    GOV - This domain was originally intended for any kind of government
  1111.          office or agency.  More recently a decision was taken to
  1112.          register only agencies of the US Federal government in this
  1113.          domain.  State and local agencies are registered in the country
  1114.          domains (see US Domain, below).
  1115.  
  1116.    MIL - This domain is used by the US military.
  1117.  
  1118.    Example country code Domain:
  1119.  
  1120.    US - As an example of a country domain, the US domain provides for 
  1121.     the registration of all kinds of entities in the United States
  1122.     on the basis of political geography, that is, a hierarchy of
  1123.     <entity-name>.<locality>.<state-code>.US.  For example,
  1124.     "IBM.Armonk.NY.US".  In addition, branches of the US domain are
  1125.     provided within each state for schools (K12), community
  1126.     colleges (CC), technical schools (TEC), state government
  1127.     agencies (STATE), councils of governments (COG),libraries
  1128.     (LIB), museums (MUS), and several other generic types of
  1129.     entities (see RFC 1480 for details).
  1130.  
  1131.  
  1132. A section from RFC 1480:
  1133.  
  1134.    2. NAMING STRUCTURE
  1135.  
  1136.        The US Domain hierarchy is based on political geography.  The
  1137.        basic name space under US is the state name space, then the
  1138.        "locality" name space, (like a city, or county) then
  1139.        organization or computer name and so on.
  1140.     
  1141.        For example:
  1142.     
  1143.               BERKELEY.CA.US
  1144.               PORTLAND.WA.US
  1145.     
  1146.        There is of course no problem with running out of names.
  1147.     
  1148.        The things that are named are individual computers.
  1149.     
  1150.        If you register now in one city and then move, the database can
  1151.        be updated with a new name in your new city, and a pointer can
  1152.        be set up from your old name to your new name.  This type of
  1153.        pointer is called a CNAME record.
  1154.     
  1155.        The use of unregistered names is not effective and causes problems
  1156.        for other users.  Inventing your own name and using it without
  1157.        registering is not a good idea.
  1158.     
  1159.        In addition to strictly geographically names, some special names
  1160.        are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC,
  1161.        CITY, and COUNTY.  Several new name spaces have been created,
  1162.        DNI, GEN, and TEC, and a minor change under the "locality" name
  1163.        space was made to the existing CITY and COUNTY subdomains by
  1164.        abbreviating them to CI and CO.  A detailed description
  1165.        follows.
  1166.     
  1167.        Below US, Parallel to States:
  1168.        -----------------------------
  1169.     
  1170.        "FED" - This branch may be used for agencies of the federal
  1171.        government.  For example: <org-name>.<city>.FED.US
  1172.     
  1173.        "DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was
  1174.        created directly under the top-level US.  This branch is to be used
  1175.        for distributed national institutes; organizations that span state,
  1176.        regional, and other organizational boundaries; that are national in
  1177.        scope, and have distributed facilities.  For example:
  1178.        <org-name>.DNI.US.
  1179.     
  1180.        Name Space Within States:
  1181.        ------------------------
  1182.     
  1183.        "locality" - cities, counties, parishes, and townships.  Subdomains
  1184.        under the "locality" would be like CI.<city>.<state>.US,
  1185.        CO.<county>.<state>.US, or businesses. For example:
  1186.        Petville.Marvista.CA.US.
  1187.     
  1188.        "CI" - This branch is used for city government agencies and is a
  1189.        subdomain under the "locality" name (like Los Angeles). For example:
  1190.        Fire-Dept.CI.Los-Angeles.CA.US.
  1191.     
  1192.        "CO" - This branch is used for county government agencies and is a
  1193.        subdomain under the "locality" name (like Los Angeles).  For example:
  1194.        Fire-Dept.CO.San-Diego.CA.US.
  1195.     
  1196.        "K12" - This branch may be used for public school districts.  A
  1197.        special name "PVT" can be used in the place of a school district name
  1198.        for private schools.  For example: <school-name>.K12.<state>.US and
  1199.        <school-name>.PVT.K12.<state>.US.
  1200.     
  1201.        "CC" - COMMUNITY COLLEGES - This branch was established for all state
  1202.        wide community colleges.  For example: <school-name>.CC.<state>.US.
  1203.     
  1204.        "TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was
  1205.        established for technical and vocational schools and colleges. For
  1206.        example: <school-name>.TEC.<state>.US.
  1207.     
  1208.        "LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may
  1209.        be used for libraries only.  For example:  <lib-name>.LIB.<state>.US.
  1210.     
  1211.        "STATE" - This branch may be used for state government agencies.  For
  1212.        example:  <org-name>.STATE.<state>.US.
  1213.     
  1214.        "GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things
  1215.        that don't fit easily into any other structure listed -- things that
  1216.        might fit in to something like ORG at the top-level.  It is best not
  1217.        to use the same keywords (ORG, EDU, COM, etc.) that are used at the
  1218.        top-level to avoid confusion.  GEN would be used for such things as,
  1219.        state-wide organizations, clubs, or domain parks.  For example:
  1220.        <org-name>.GEN.<state-code>.US.
  1221.  
  1222.    The application form for the US domain may be found for anonymous ftp 
  1223.    from:
  1224.  
  1225.        ftp://internic.net/templates/us-domain-template.txt
  1226.  
  1227.    The application form for the EDU, COM, NET, ORG, and  GOV domains may be 
  1228.    found for anonymous ftp from:
  1229.  
  1230.        ftp://internic.net/templates/domain-template.txt
  1231.  
  1232.  
  1233. -------------------------------
  1234.  
  1235. Date: Sun Nov 27 23:32:41 EST 1994
  1236. Subject: Q3.8 - Classes of networks
  1237.  
  1238. Q: I am just kind of curious to what exactly the differences in classes
  1239.    of networks are (class A, B, C).  
  1240.  
  1241. A: An Internet Protocol (IP) address is 32 bit in length, divided into 
  1242.    two or three parts (the network address, the subnet address (if present),
  1243.    and the host address.  The subnet addresses are only present if the
  1244.    network has been divided into subnetworks.  The length of the network,
  1245.    subnet, and host field are all variable. 
  1246.  
  1247.    There are five different network classes.  The leftmost bits indicate 
  1248.    the class of the network.
  1249.  
  1250.       # bits in  # bits in
  1251.        network     host
  1252. Class   field     field   Internet Protocol address in binary  Ranges
  1253. ============================================================================
  1254.   A       7         24    0NNNNNNN.HHHHHHHH.HHHHHHHH.HHHHHHHH    1-127.x.x.x
  1255.   B      14         16    10NNNNNN.NNNNNNNN.HHHHHHHH.HHHHHHHH  128-191.x.x.x
  1256.   C      22          8    110NNNNN.NNNNNNNN.NNNNNNNN.HHHHHHHH  192-223.x.x.x
  1257.   D      NOTE 1           1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx  224-239.x.x.x
  1258.   E      NOTE 2           11110xxx.xxxxxxxx.xxxxxxxx.xxxxxxxx  240-247.x.x.x
  1259.  
  1260.    where N represents part of the network address and H represents part of 
  1261.    the host address.   When the subnet address is defined, the needed bits 
  1262.    are assigned from the host address space.
  1263.  
  1264.    NOTE 1: Reserved for multicast groups - RFC 1112
  1265.    NOTE 2: Reserved for future use
  1266.  
  1267.    127.0.0.1 is reserved for local loopback.
  1268.  
  1269.    Under the current arrangements, many class A IP numbers will not be
  1270.    assigned whereas class C usage will be at a premium.   
  1271.  
  1272. -------------------------------
  1273.  
  1274.  
  1275. Date: Fri Apr 28 13:31:24 EDT 1995
  1276. Subject: Q3.9 - What is CIDR ?
  1277.  
  1278. Q: What is CIDR ?
  1279.  
  1280. A: CIDR is "Classless Inter-Domain Routing (CIDR).  From RFC1517:
  1281.  
  1282.       ...Classless Inter-Domain Routing (CIDR) attempts to deal with 
  1283.       these problems by defining a mechanism to slow the growth of 
  1284.       routing tables and reduce the need to allocate new IP network 
  1285.       numbers.  
  1286.  
  1287.    Much more information may be obtained in RFCs 1467, 1517, 1518, 1520; 
  1288.    with primary reference 1519
  1289.  
  1290.  
  1291. -------------------------------
  1292.  
  1293.  
  1294. Date: Fri Apr 28 13:31:24 EDT 1995
  1295. Subject: Q3.10 - What is the rule for glue ?
  1296.  
  1297. Q: What is the rule for glue ?
  1298.  
  1299. A: A glue record is an A record for a name that appears on the right-hand 
  1300.    side of a NS record.  So, if you have this:
  1301.  
  1302.         sub.foobar.com.        IN      NS      dns.sub.foobar.com.
  1303.         dns.sub.foobar.com.    IN      A       1.2.3.4
  1304.  
  1305.    then the second record is a glue record (for the NS record above it).
  1306.  
  1307.    You need glue records when -- and only when -- you are delegating
  1308.    authority to a nameserver that "lives" in the domain you are delegating 
  1309.    *and* you aren't a secondary server for that domain.
  1310.  
  1311.    In other words, in the example above, you need to add an A record
  1312.    for dns.sub.foobar.com since it "lives" in the domain it serves.
  1313.    This boot strapping information is necessary:  How are you supposed
  1314.    to find out the IP address of the nameserver for domain FOO if the
  1315.    nameserver for FOO "lives" in FOO?
  1316.  
  1317.    If you have this NS record:
  1318.  
  1319.         sub.foobar.com.         IN      NS      dns.xyz123.com.
  1320.  
  1321.    you do NOT need a glue record, and, in fact, adding one is a very
  1322.    bad idea.  If you add one, and then the folks at xyz123.com change
  1323.    the address, then you will be passing out incorrect data.
  1324.  
  1325.    Also, unless you actually have a machine called something.IN-ADDR.ARPA, 
  1326.    you will never have any glue records present in any of your "reverse" 
  1327.    files.
  1328.  
  1329.    There is also a sort of implicit glue record that can be useful (or 
  1330.    confusing :^) ).  If the parent server (abc.foobar.com domain in example
  1331.    above) is a secondary server for the child, then the A record will be
  1332.    fetched from the child server when the zone transfer is done.  The glue
  1333.    is still there but it's a little different, it's in the ip address in 
  1334.    the named.boot line instead of explicitly in the data.  In this case 
  1335.    you can leave out the explicit glue A record and leave the manually 
  1336.    configured "glue" in just the one place in the named.boot file. 
  1337.  
  1338.    RFC 1537 says it quite nicely:
  1339.  
  1340.       2. Glue records
  1341.  
  1342.          Quite often, people put unnecessary glue (A) records in their 
  1343.          zone files. Even worse is that I've even seen *wrong* glue records 
  1344.          for an external host in a primary zone file! Glue records need only 
  1345.          be in a zone file if the server host is within the zone and there 
  1346.          is no A record for that host elsewhere in the zone file.
  1347.  
  1348.          Old BIND versions ("native" 4.8.3 and older versions) showed the
  1349.          problem that wrong glue records could enter secondary servers in
  1350.          a zone transfer.
  1351. From: cdp@njit.edu (Chris Peckham)
  1352. Subject: comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
  1353. Originator: cdp2582@hertz.njit.edu
  1354. Keywords: BIND,DOMAIN,DNS
  1355. Sender: news@njit.edu
  1356. Reply-To: domain-faq@njit.edu (comp.protocols.tcp-ip.domains FAQ comments)
  1357. Organization: NJIT.EDU - New Jersey Institute of Technology, Newark, NJ, USA
  1358. Date: Tue, 4 Jul 1995 04:17:31 GMT
  1359. Expires: Tue 08 Aug 95 00:17:18 EDT
  1360. Lines: 1107
  1361.  
  1362. Posted-By: auto-faq 3.1.1.2
  1363. Archive-name: internet/tcp-ip/domains-faq/part2
  1364. Revision: 1.5 1995/05/12 18:50:41
  1365.  
  1366.  
  1367. This FAQ is edited and maintained by Chris Peckham, <cdp@njit.edu>. 
  1368. The latest version may always be found for anonymous ftp from
  1369.  
  1370.     ftp://rtfm.mit.edu/pub/usenet/news.answers/internet/tcp-ip/domains-faq
  1371.     ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ
  1372.  
  1373. If you can contribute any answers for items in the TODO section, please do
  1374. so by sending e-mail to domain-faq@njit.edu !  If you know of any items that 
  1375. are not included and you feel that they should be,  send the relevant
  1376. information to domain-faq@njit.edu.
  1377.  
  1378.  
  1379. ------------------------------
  1380.  
  1381. Date: Fri May 12 14:41:47 EDT 1995
  1382. Subject: Table of Contents
  1383.  
  1384. Table of Contents
  1385. =================
  1386. Part 1
  1387. ------
  1388.    0. TO DO
  1389.    1. INTRODUCTION / MISCELLANEOUS
  1390.       1.1  What is this newsgroup ?
  1391.       1.2  More information
  1392.       1.3  What is BIND and where is the latest version of BIND ?
  1393.       1.4  How can I find the route between systems ?
  1394.       1.5  Finding the hostname if you have the tcp-ip address
  1395.       1.6  How to register a domain name
  1396.       1.7  Change of Domain name
  1397.       1.8  How memory and CPU does DNS use ?
  1398.       1.9  Other things to consider when planning your servers  
  1399.       1.10 Proper way to get NS and reverse IP records into DNS
  1400.       1.11 How to get my address assign from NIC?
  1401.       1.12 Is there a block of private IP addresses I can use?
  1402.       1.13 Cache failed lookups
  1403.       1.14 What does an NS record really do ?
  1404.       1.15 DNS ports
  1405.       1.16 Obtaining the latest cache file 
  1406.    2. UTILITIES
  1407.       2.1  Utilities to administer DNS zone files
  1408.       2.2  DIG - Domain Internet Groper
  1409.       2.3  DNS packet analyzer
  1410.       2.4  host 
  1411.       2.5  Programming with DNS
  1412.       2.6  A source of information relating to DNS
  1413.    3. DEFINITIONS
  1414.       3.1  TCP/IP Host Naming Conventions
  1415.       3.2  Slaves and servers with forwarders
  1416.       3.3  When is a server authoritative?
  1417.       3.4  Underscore in host-/domain names
  1418.       3.5  Lame delegation
  1419.       3.6  What does opt-class field do?
  1420.       3.7  Top level domains
  1421.       3.8  Classes of networks
  1422.       3.9  What is CIDR ?
  1423.       3.10 What is the rule for glue ?
  1424.  
  1425. Part 2
  1426. ------
  1427.    4. CONFIGURATION
  1428.       4.1  Changing a Secondary server to a Primary
  1429.       4.2  How do I subnet a Class B Address ?
  1430.       4.3  Subnetted domain name service
  1431.       4.4  Recommended format/style of DNS files
  1432.       4.5  DNS on a system not connected to the Internet
  1433.       4.6  Multiple Domain configuration
  1434.       4.7  wildcard MX records
  1435.       4.8  How to identify a wildcard MX record
  1436.       4.9  Why are fully qualified domain names recommended ?
  1437.       4.10 Distributing load using named
  1438.       4.11 Order of returned records
  1439.       4.12 resolv.conf 
  1440.       4.13 Delegating authority 
  1441.       4.14 DNS instead of NIS on a Sun OS 4.1.x system
  1442.    5. PROBLEMS
  1443.       5.1  No address for root server
  1444.       5.2  Error - No Root Nameservers for Class XX
  1445.       5.3  Bind 4.9.x and MX querying?
  1446.       5.4  Some root nameservers don't know localhost
  1447.       5.5  MX records and CNAMES and separate A records for MX targets
  1448.       5.6  NS is a CNAME
  1449.       5.7  Nameserver forgets own A record
  1450.       5.8  General problems (core dumps !)
  1451.       5.9  malloc and DECstations
  1452.    6. ACKNOWLEDGEMENTS
  1453.  
  1454. ------------------------------
  1455.  
  1456. Date: Fri Dec  2 15:31:06 EST 1994
  1457. Subject: Q4.1 - Changing a Secondary server to a Primary
  1458.  
  1459. Q: Do I need to do anything special when I change a server from a secondary 
  1460.    to a primary ?
  1461.  
  1462. A: For 4.8.3,  it's prudent to kill and restart following any changes to
  1463.    named.boot.
  1464.  
  1465.    In BIND 4.9.3, you only have to kill and restart named if you change
  1466.    a primary zone to a secondary or v-v, or if you delete a zone and
  1467.    remain authoritative for its parent.  Every other case should be
  1468.    taken care of by a HUP.  (Ed. note: 4.9.3b9 may still require you to
  1469.    kill and restart the server due to some bugs in the HUP code).
  1470.  
  1471.    You will also need to update the server information on the root servers.
  1472.    You can do this by filing a new domain registration form to inform 
  1473.    InterNIC of the change.  They will then update the root server's SOA
  1474.    records.  This process usually takes 10-12 business days after they
  1475.    receive the request.
  1476.  
  1477. -------------------------------
  1478.  
  1479. Date: Fri Apr 28 13:34:52 EDT 1995
  1480. Subject: Q4.2 - How do I subnet a Class B Address ?
  1481.  
  1482. Q: I just received a Class B internet address and I am wondering where to
  1483.    get an RFC or other information on how to properly to the TCP/IP
  1484.    sub-netting.
  1485.  
  1486. A: That you need to subnet at all is something of a misconception.  You
  1487.    can also think of a class B network as giving you 65,534 individual
  1488.    hosts, and such a network will work. You can also configure your
  1489.    class B as 16,384 networks of 2 hosts each.  That's obviously not
  1490.    very practical, but it needs to be made clear that you are not
  1491.    constrained by the size of an octet (remember that many older
  1492.    devices would not work in a network configured in this manner).
  1493.  
  1494.    So, the question is: why do you need to subnet?   One reason is that
  1495.    it is easier to manage a subnetted network, and in fact, you can
  1496.    delegate the responsibility for address space management to local
  1497.    administrators on the various subnets.  Also, IP based problems will
  1498.    end up localized rather than affecting your entire network.
  1499.    
  1500.    If your network is a large backbone with numerous segments
  1501.    individually branching off the backbone, that too suggests
  1502.    subnetting.
  1503.  
  1504.    Subnetting can also be used to improve routing conditions.
  1505.  
  1506.    You may wish to partition your network to disallow certain protocols 
  1507.    on certain segments of your net.  You can, for example, restrict IP or
  1508.    IPX to certain segments only by adding a router routing high level 
  1509.    protocols, and across the router you may have to subnet. 
  1510.  
  1511.    Finally, as far as how many subnets you need depends on the answer to
  1512.    the above question.  As far as subnet masks are concerned, the mask
  1513.    can be anything from 255.0.0.0 to 255.255.255.252.  You'll probably be
  1514.    looking at 9 or 10 bits for the subnet (last octet 128 or 192
  1515.    respectively).  RFC1219 discusses the issue of subnetting very well 
  1516.    and leaves the network administrator with a large amount of flexibility
  1517.    for future growth.
  1518.  
  1519.  
  1520. ------------------------------
  1521.  
  1522. Date: Sun Nov 27 23:32:41 EST 1994
  1523. Subject: Q4.3 -Subnetted domain name service
  1524.  
  1525. Q: After doing some reading (DNS and BIND, Albitz&Liu), I don't really
  1526.    find any examples of handling subnetted class C networks as separate
  1527.    DNS domains.
  1528.  
  1529. A: This is possible, just messy.   You need to delegate down to the
  1530.    fourth octet, so you will have one domain per IP address !  Here is
  1531.    how you can subdelegate a in-addr.arpa address for non-byte aligned 
  1532.    subnet masks:
  1533.  
  1534.    Take as an example the net 192.1.1.x, and example subnet mask 
  1535.    255.255.255.240.
  1536.  
  1537.    We first define the domain for the class C net,
  1538.  
  1539. $origin  1.1.192.in-addr.arpa
  1540. @       SOA   (usual stuff)
  1541. @       ns  some.nameserver
  1542.         ns  some.other.nameserver
  1543. ; delegate a subdomain
  1544. one     ns  one.nameserver
  1545.         ns  some.nameserver
  1546. ; delegate another
  1547. two     ns  two.nameserver
  1548.         ns  some.nameserver
  1549. ; CNAME pointers to subdomain one
  1550. 0       CNAME 0.one
  1551. 1       CNAME 1.one
  1552. ;    through
  1553. 15      CNAME 15.one
  1554. ; CNAME pointers to subdomain two
  1555. 16      CNAME 16.two
  1556. 17      CNAME 17.two
  1557. 31      CNAME 31.two
  1558. ; CNAME as many as required.
  1559.  
  1560.  
  1561.    Now, in the delegated nameserver, one.nameserver
  1562.  
  1563. $origin one.1.1.192.in-addr.arpa
  1564. @       SOA (usual stuff)
  1565.         NS  one.nameserver
  1566.         NS  some.nameserver   ;  secondary for us
  1567. 0       PTR  onenet.one.domain
  1568. 1       PTR  onehost.one.domain
  1569. ;   through
  1570. 15      PTR  lasthost.one.domain
  1571.  
  1572.    And similar for the two.1.1.192.in-addr.arpa delegated domain.
  1573.  
  1574.  
  1575. ------------------------------
  1576.  
  1577. Date: Sun Nov 27 23:32:41 EST 1994
  1578. Subject: Q4.4 - Recommended format/style of DNS files
  1579.  
  1580. Q:  Are there any suggestions for how to layout DNS configuration files
  1581.     (both forward and reverse)?
  1582.  
  1583. A: This answer is quoted from an article posted by Paul Vixie:
  1584.  
  1585.    I've gone back and forth on the question of whether the BOG should
  1586.    include a section on this topic.  I know what I myself prefer, but
  1587.    I'm wary of ramming my own stylistic preferences down the throat of
  1588.    every BOG reader.  But since you ask :-)...
  1589.  
  1590.    Create /var/named.  If your system is too old to have a /var, either
  1591.    create one or use /usr/local/adm/named instead.  Put your named.boot
  1592.    in it, and make /etc/named.boot a symlink to it.  If your system
  1593.    doesn't have symlinks, you're S-O-L (but you knew that).  In
  1594.    named.boot, put a "directory" directive that specifies your actual
  1595.    BIND working directory:
  1596.  
  1597.         directory       /var/named
  1598.  
  1599.    All relative pathnames used in "primary", "secondary", and "cache"
  1600.    directives will be evaluated relative to this directory.  Create two
  1601.    subdirectories, /var/named/pri and /var/named/sec.  Whenever you add
  1602.    a "primary" directive to your named.boot, use "pri/WHATEVER" as the
  1603.    path name.  And then put the primary zone file into "pri/WHATEVER".
  1604.    Likewise when you add "secondary" directives, use "sec/WHATEVER" and
  1605.    BIND (really named-xfer) will create the files in that
  1606.    subdirectory.
  1607.  
  1608.    (Variations: (1) make a midlevel directory "zones" and put "pri" and
  1609.    "sec" into it; (2) if you tend to pick up a lot of secondaries from
  1610.    a few hosts, group them together in their own subdirectories --
  1611.    something like /var/named/zones/uucp if you're a UUCP Project name
  1612.    server.)
  1613.  
  1614.    For your forward files, name them after the zone.  dec.com becomes
  1615.    "/var/named/zones/pri/dec.com".  For your reverse files, name them
  1616.    after the network number.  0.1.16.in-addr.arpa becomes
  1617.    "/var/named/zones/pri/16.1.0".
  1618.  
  1619.    When creating or maintaining primary zone files, try to use the same
  1620.    SOA values everywhere, except for the serial number which varies per
  1621.    zone.  Put a $ORIGIN directive at the top of the primary zone file,
  1622.    not because its needed (it's not since the default origin is the
  1623.    zone named in the "primary" directive) but because it make it easier
  1624.    to remember what you're working on when you have a lot of primary
  1625.    zones.  Put some comments up there indicating contact information
  1626.    for the real owner if you're proxying.  Use RCS and put the "Id"
  1627.    in a ";" comment near the top of the zone file.
  1628.  
  1629.    The SOA and other top level information should all be listed
  1630.    together.  But don't put IN on every line, it defaults nicely.  For
  1631.    example:
  1632.  
  1633. ==============
  1634. @       IN      SOA     gw.home.vix.com. postmaster.vix.com. (
  1635.                         1994082501      ; serial
  1636.                         3600    ; refresh (1 hour)
  1637.                         1800    ; retry (30 mins)
  1638.                         604800  ; expire (7 days)
  1639.                         3600 )  ; minimum (1 hour)
  1640.  
  1641.                 NS      gw.home.vix.com.
  1642.                 NS      ns.uu.net.
  1643.                 NS      uucp-gw-1.pa.dec.com.
  1644.                 NS      uucp-gw-2.pa.dec.com.
  1645.  
  1646.                 MX      10 gw.home.vix.com.
  1647.                 MX      20 uucp-gw-1.pa.dec.com.
  1648.                 MX      20 uucp-gw-1.pa.dec.com.
  1649. ==============
  1650.  
  1651.    I don't necessarily recommend those SOA values.  Not every zone is
  1652.    as volatile as the example shown.  I do recommend that serial number
  1653.    format; it's in date format with a 2-digit per-day revision number.
  1654.    This format will last us until 2147 A.D. at which point I expect a
  1655.    better solution will have been found :-).  (Note that it would last
  1656.    until 4294 A.D. except that there are some old BINDs out there that
  1657.    use a signed quantity for representing serial number interally; I
  1658.    suppose that as long as none of these are still running after 2047
  1659.    A.D., that we can use the above serial number format until 4294
  1660.    A.D., at which point a better solution will HAVE to be found.)
  1661.  
  1662.    You'll note that I use a tab stop for "IN" even though I never again
  1663.    specify it.  This leaves room for names longer than 7 bytes without
  1664.    messing up the columns.  You might also note that I've put the MX
  1665.    priority and destination in the same tab stop; this is because both
  1666.    are part of the RRdata and both are very different from MX which is
  1667.    an RRtype.  Some folks seem to prefer to group "MX" and the priority
  1668.    together in one tab stop.  While this looks neat it's very confusing
  1669.    to newcomers and for them it violates the law of least
  1670.    astonishment.
  1671.  
  1672.    If you have a multi-level zone (one which contains names that have
  1673.    dots in them), you can use additional $ORIGIN statements but I
  1674.    recommend against it since there is no "back" operator.  That is,
  1675.    given the above example you can add:
  1676.  
  1677. =============
  1678. $ORIGIN home
  1679. gw              A       192.5.5.1
  1680. =============
  1681.  
  1682.    The problem with this is that subsequent RR's had better be
  1683.    somewhere under the "home.vix.com" name or else the $ORIGIN that
  1684.    introduces them will have to use a fully qualified name.  FQDN
  1685.    $ORIGIN's aren't bad and I won't be mad if you use them.
  1686.    Unqualified ones as shown above are real trouble.  I usually stay
  1687.    away from them and just put the whole name in:
  1688.  
  1689. =============
  1690. gw.home         A       192.5.5.1
  1691. =============
  1692.  
  1693.    In your reverse zones, you're usually in some good luck because the
  1694.    owner name is usually a single short token or sometimes two.
  1695.  
  1696. =============
  1697. $ORIGIN 5.5.192.in-addr.arpa.
  1698. @       IN      SOA     ...
  1699.                 NS      ...
  1700. 1               PTR     gw.home.vix.com.
  1701. =========================================
  1702. $ORIGIN 1.16.in-addr.arpa.
  1703. @       IN      SOA     ...
  1704.                 NS      ...
  1705. 2.0             PTR     gatekeeper.dec.com.
  1706. =============
  1707.  
  1708.    It is usually pretty hard to keep your forward and reverse zones in
  1709.    synch.  You can avoid that whole problem by just using "h2n" (see
  1710.    the ORA book, DNS and BIND, and its sample toolkit, included in the
  1711.    BIND distribution or on ftp.uu.net (use the QUOTE SITE EXEC INDEX
  1712.    command there to find this -- I never can remember where it's at).
  1713.    "h2n" and many tools like it can just read your old /etc/hosts file
  1714.    and churn it into DNS zone files.  (May I recommend
  1715.    contrib/decwrl/mkdb.pl from the BIND distribution?)  However, if you
  1716.    (like me) prefer to edit these things by hand, you need to follow
  1717.    the simple convention of making all of your holes consistent.  If
  1718.    you use 192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in
  1719.    your forward file you will have something like
  1720.  
  1721. =============
  1722. ...
  1723. gw.home         A       192.5.5.1
  1724. ;avail          A       192.5.5.2
  1725. pc.home         A       192.5.5.3
  1726. =============
  1727.  
  1728.    and in your reverse file you will have something like
  1729.  
  1730. =============
  1731. ...
  1732. 1               PTR     gw.home.vix.com.
  1733. ;2              PTR     avail
  1734. 3               PTR     pc.home.vix.com.
  1735. =============
  1736.  
  1737.    This convention will allow you to keep your sanity and make fewer
  1738.    errors.  Any kind of automation (h2n, mkdb, or your own
  1739.    perl/tcl/awk/python tools) will help you maintain a consistent
  1740.    universe even if it's also a complex one.  Editing by hand doesn't
  1741.    have to be deadly but you MUST take care.
  1742.  
  1743. ------------------------------
  1744.  
  1745. Date: Sun Nov 27 23:32:41 EST 1994
  1746. Subject: Q4.5 - DNS on a system not connected to the Internet
  1747.  
  1748.  
  1749. Q: How do I use DNS on a system that is not connected to the Internet or
  1750.    set BIND up with an internal root server ?
  1751.  
  1752. A: You need to create your own root domain name server until you connect 
  1753.    to the internet.  Your roots need to delegate to mydomain.com and any
  1754.    in-addr.arpa subdomains you might have, and that's about it.  As
  1755.    soon as you're connected, rip out the fake roots and use the real
  1756.    ones.
  1757.  
  1758.    It does not actually have to be another server pretending to be the root.
  1759.    You can set up the name server so that it is primary for each domain
  1760.    above you and leave them empty (i.e. you are foo.bar.com - claim to be
  1761.    primary for bar.com and com)
  1762.  
  1763. Q: What if you connect intermittently and want DNS to work when you are
  1764.    connected, and "fail" when you are not ?
  1765.  
  1766. A: You can point the resolver at the name server at the remote site and
  1767.    if the connection (SLIP/PPP) isn't up, the resolver doesn't have a
  1768.    route to the remote server and since there's only one name server in
  1769.    resolv.conf, the resolver quickly backs off the using /etc/hosts.
  1770.    No problem.  You could do the same with multiple name server and a
  1771.    resolver that did configurable /etc/hosts fallback.
  1772.  
  1773. ------------------------------
  1774.  
  1775. Date: Fri Dec  2 15:40:49 EST 1994
  1776. Subject: Q4.6 -Multiple Domain configuration
  1777.  
  1778.  
  1779. Q: I have seen sites that seem to have multiple domain names pointing to the
  1780.    same destination. I would like to implement this and have found no
  1781.    information explaining how to do it. What I would like to do is:
  1782.  
  1783.       ftp ftp.biff.com connects user to -> ftp.biff.com
  1784.       ftp ftp.fred.com connects user to -> ftp.biff.com
  1785.       ftp ftp.bowser.com connects user to -> ftp.biff.com
  1786.  
  1787. A: This is done through CNAME records:
  1788.  
  1789.       ftp.bowser.com.         IN      CNAME ftp.biff.com.
  1790.  
  1791.     You can also do the same thing with multiple A records.
  1792.    
  1793.  
  1794. ------------------------------
  1795.  
  1796. Date: Sun Nov 27 23:32:41 EST 1994
  1797. Subject: Q4.7 - wildcard MX records
  1798.  
  1799. Q: Does BIND not understand wildcard MX records such as the following?
  1800.  
  1801.      *.foo.com       MX      0       mail.foo.com.
  1802.  
  1803. A: Explicit RR's at one level of specificity will, by design, "block" a
  1804.    wildcard at a lesser level of specificity. I suspect that you have
  1805.    an RR (an A RR, perhaps?) for "bar.foo.com" which is blocking the
  1806.    application of your "*.foo.com" wildcard. The initial MX query is
  1807.    thus failing (NOERROR but an answer count of 0), and the backup
  1808.    query finds the A RR for "bar.foo.com" and uses it to deliver the
  1809.    mail directly (which is what you DIDN'T want it to do).  Adding an
  1810.    explicit MX RR for the host is therefore the right way to handle
  1811.    this situation.
  1812.  
  1813.    See RFC 1034, Section 4.3.3 ("Wildcards") for more information on
  1814.    this "blocking" behavior, along with an illustrative example. See
  1815.    also RFC 974 for an explanation of standard mailer behavior in the
  1816.    face of an "empty" response to one's MX query.
  1817.  
  1818.    Basically, what it boils down to is, there is no point in trying to
  1819.    use a wildcard MX for a host which is otherwise listed in the DNS.
  1820.    It just doesn't work.
  1821.  
  1822. ------------------------------
  1823.  
  1824. Date: Thu Dec  1 11:10:39 EST 1994
  1825. Subject: Q4.8 - How to identify a wildcard MX record
  1826.  
  1827.  
  1828. Q: How do you identify a wildcard MX record ?
  1829.  
  1830. A: You don't really need to "identify" a wildcard MX RR.  The precedence 
  1831.    for u@dom is:
  1832.  
  1833.         exact match MX
  1834.         exact match A
  1835.         wildcard MX
  1836.  
  1837.    One way to implement this is to query for ("dom",IN,MX) and if the
  1838.    answer name that comes back is "*." something, you know it's a
  1839.    wildcard, therefore you know there is no exact match MX, and you
  1840.    therefore query for ("dom",IN,A) and if you get something, use it.
  1841.    if you don't, use the previous wildcard response.
  1842.  
  1843.    RFC 974 explains this pretty well.
  1844.  
  1845. ------------------------------
  1846.  
  1847. Date: Sun Nov 27 23:32:41 EST 1994
  1848. Subject: Q4.9 - Why are fully qualified domain names recommended ?
  1849.  
  1850.  
  1851. Q: Why are fully qualified domain names recommended ?
  1852.  
  1853. A: The documentation for BIND 4.9.2 says that the hostname should be set 
  1854.    to the full domain style name (i.e host.our.domain rather than
  1855.    host).  What advantages are there in this, and are there any adverse
  1856.    consequences if we don't?
  1857.  
  1858. A: Paul Vixie likes to do it :-)  He lists a few reasons -
  1859.  
  1860.    * Sendmail can be configured to just use Dj$w rather than
  1861.      Dj$w.mumble where "mumble" is something you have to edit in by
  1862.      hand.  Granted, most people use "mumble" elsewhere in their config
  1863.      files ("tack on local domain", etc) but why should it be a
  1864.      requirement ?
  1865.  
  1866.    * The real reason is that not doing it violates a very useful invariant:
  1867.  
  1868.     gethostbyname(gethostname) == gethostbyaddr(primary_interface_address)
  1869.  
  1870.      If you take an address and go "backwards" through the PTR's with
  1871.      it, you'll get a FQDN, and if you push that back through the A
  1872.      RR's, you get the same address.  Or you should.  Many multi-homed
  1873.      hosts violate this uncaringly.
  1874.  
  1875.      If you take a non-FQDN hostname and push it "forwards" through the
  1876.      A RR's, you get an address which, if you push it through the
  1877.      PTR's, comes back as a FQDN which is not the same as the hostname
  1878.      you started with.  Consider the fact that, absent NIS/YP, there is
  1879.      no "domainname" command analogous to the "hostname" command.
  1880.      (NIS/YP's doesn't count, of course, since it's
  1881.      sometimes-but-only-rarely the same as the Internet domain or
  1882.      subdomain above a given host's name.)  The "domain" keyword in
  1883.      resolv.conf doesn't specify the parent domain of the current host;
  1884.      it specifies the default domain of queries initiated on the
  1885.      current host, which can be a very different thing.  (As of RFC
  1886.      1535 and BIND 4.9.2's compliance with it, most people use "search"
  1887.      in resolv.conf, which overrides "domain", anyway.)
  1888.  
  1889.      What this means is that there is NO authoritative way to
  1890.      programmatically discover your host's FQDN unless it is set in the
  1891.      hostname, or unless every application is willing to grovel the
  1892.      "netstat -in" tables, find what it hopes is the primary address,
  1893.      and do a PTR query on it.
  1894.  
  1895.      FQDN /bin/hostnames are, intuitively or not, the simplest way to go.
  1896.  
  1897. ------------------------------
  1898.  
  1899. Date: Wed Mar  1 11:04:43 EST 1995
  1900. Subject: Q4.10 - Distributing load using named
  1901.  
  1902. Q: If you attempt to distribute the load on a system using named, won't 
  1903.    the first response be cached, and then later queries use the cached
  1904.    value? (This would be for requests that come through the same
  1905.    server.)
  1906.  
  1907. A: Yes.  So it can be useful to use a lower TTL on records where this is
  1908.    important.  You can use values like 300 or 500 seconds.
  1909.  
  1910.    If your local caching server has ROUND_ROBIN, it does not matter
  1911.    what the authoritative servers have -- every response from the cache
  1912.    is rotated.
  1913.  
  1914.    But if it doesn't, and the authoritative server site is depending on
  1915.    this feature (or the old "shuffle-A") to do load balancing, then if
  1916.    one doesn't use small TTLs, one could conceivably end up with a
  1917.    really nasty situation, e.g., hundreds of workstations at a branch
  1918.    campus pounding on the same front end at the authoritative server's
  1919.    site during class registration.
  1920.  
  1921.    Not nice.
  1922.  
  1923. A: Paul Vixie has an example of the ROUND_ROBIN code in action.  Here is 
  1924.    something that he wrote regarding his example:
  1925.  
  1926.      >I want users to be distributed evenly among those 3 hosts.
  1927.  
  1928.      Believe it or not :-), BIND offers an ugly way to do this.  I offer
  1929.      for your collective amusement the following snippet from the
  1930.      ugly.vix.com zone file:
  1931.  
  1932.        hydra           cname        hydra1
  1933.                        cname        hydra2
  1934.                        cname        hydra3
  1935.        hydra1          a            10.1.0.1
  1936.                        a            10.1.0.2
  1937.                        a            10.1.0.3
  1938.        hydra2          a            10.2.0.1
  1939.                        a            10.2.0.2
  1940.                        a            10.2.0.3
  1941.        hydra3          a            10.3.0.1
  1942.                        a            10.3.0.2
  1943.                        a            10.3.0.3
  1944.        
  1945.       Note that having multiple CNAME RR's at a given name is
  1946.       meaningless according to the DNS RFCs but BIND doesn't mind (in
  1947.       fact it doesn't even complain).  If you call
  1948.       gethostbyname("hydra.ugly.vix.com") (try it!) you will get
  1949.       results like the following.  Note that there are two round robin
  1950.       rotations going on: one at ("hydra",CNAME) and one at each
  1951.       ("hydra1",A) et al.  I used a layer of CNAME's above the layer of
  1952.       A's to keep the response size down.  If you don't have nine
  1953.       addresses you probably don't care and would just use a pile of
  1954.       CNAME's pointing directly at real host names.
  1955.  
  1956.       {hydra.ugly.vix.com}
  1957.       name: hydra2.ugly.vix.com
  1958.       aliases: hydra.ugly.vix.com
  1959.       addresses: 10.2.0.2 10.2.0.3 10.2.0.1
  1960.  
  1961.       {hydra.ugly.vix.com}
  1962.       name: hydra3.ugly.vix.com
  1963.       aliases: hydra.ugly.vix.com
  1964.       addresses: 10.3.0.2 10.3.0.3 10.3.0.1
  1965.  
  1966.       {hydra.ugly.vix.com}
  1967.       name: hydra1.ugly.vix.com
  1968.       aliases: hydra.ugly.vix.com
  1969.       addresses: 10.1.0.2 10.1.0.3 10.1.0.1
  1970.  
  1971.       {hydra.ugly.vix.com}
  1972.       name: hydra2.ugly.vix.com
  1973.       aliases: hydra.ugly.vix.com
  1974.       addresses: 10.2.0.3 10.2.0.1 10.2.0.2
  1975.  
  1976.       {hydra.ugly.vix.com}
  1977.       name: hydra3.ugly.vix.com
  1978.       aliases: hydra.ugly.vix.com
  1979.       addresses: 10.3.0.3 10.3.0.1 10.3.0.2
  1980.  
  1981.  
  1982. ------------------------------
  1983.  
  1984. Date: Sun Dec  4 22:12:32 EST 1994
  1985. Subject: Q4.11 - Order of returned records
  1986.  
  1987. Q: Is there any way to tell named to return records, specifically
  1988.    address records, in the order in which they are listed in the
  1989.    database?
  1990.  
  1991.    It would appear that named consistently applies a sorting algorithm
  1992.    to address records which seems to be virtually guaranteed to be
  1993.    pessimal for our routers, which have many A records.
  1994.  
  1995. A: Sorting, is the *resolver's* responsibility.  RFC 1123:
  1996.  
  1997.          6.1.3.4  Multihomed Hosts
  1998.  
  1999.             When the host name-to-address function encounters a host
  2000.             with multiple addresses, it SHOULD rank or sort the
  2001.             addresses using knowledge of the immediately connected
  2002.             network number(s) and any other applicable performance or
  2003.             history information.
  2004.  
  2005.             DISCUSSION:
  2006.                  The different addresses of a multihomed host generally
  2007.                  imply different Internet paths, and some paths may be
  2008.                  preferable to others in performance, reliability, or
  2009.                  administrative restrictions.  There is no general way
  2010.                  for the domain system to determine the best path.  A
  2011.                  recommended approach is to base this decision on local
  2012.                  configuration information set by the system
  2013.                  administrator.
  2014.  
  2015.    In BIND 4.9.x's resolver code, the "sortlist" directive in resolv.conf 
  2016.    can be used to configure this.
  2017.  
  2018. ------------------------------
  2019.  
  2020. Date: Fri Feb 10 15:46:17 EST 1995
  2021. Subject: Q4.12 - resolv.conf
  2022.  
  2023.  
  2024. Q: Why should I use "real" IP addresses in /etc/resolv.conf and not 0.0.0.0 
  2025.    or 127.0.0.1.
  2026.  
  2027. A: Paul Vixie writes on the issue of the contents of resolv.conf:
  2028.  
  2029.    It's historical.  Some kernels can't unbind a UDP socket's source
  2030.    address, and some resolver versions (notably not including BIND
  2031.    4.9.2 or 4.9.3's) try to do this.  The result can be wide area
  2032.    network traffic with 127.0.0.1 as the source address.  Rather than
  2033.    giving out a long and detailed map of version/vendor combinations of
  2034.    kernels/BINDs that have/don't this problem, I just tell folks not to
  2035.    use 127.0.0.1 at all.
  2036.  
  2037.    0.0.0.0 is just an alias for the first interface address assigned
  2038.    after a system boot, and if that interface is a up-and-down point to
  2039.    point link (PPP, SLIP, whatever), there's no guarantee that you'll
  2040.    be able to reach yourself via 0.0.0.0 during the entire lifetime of
  2041.    any system instance.  On most kernels you can finesse this by adding
  2042.    static routes to 127.0.0.1 for each of your interface addresses, but
  2043.    some kernels don't like that trick and rather than give a detailed
  2044.    map of which ones work and which ones don't, I just globally
  2045.    recommend against 0.0.0.0.
  2046.  
  2047.    If you know enough to know that 127.0.0.1 or 0.0.0.0 is safe on your
  2048.    kernel and resolver, then feel free to use them.  If you don't know
  2049.    for sure that it is safe, don't use them.  I never use them (except
  2050.    on my laptop, whose hostname is "localhost" and whose 0.0.0.0 is
  2051.    127.0.0.1 since I ifconfig my lo0 before any other interface).  The
  2052.    operational advantage to using a real IP address rather than an
  2053.    wormhole like 0.0.0.0 or 127.0.0.1, is that you can then "rdist" or
  2054.    otherwise share identical copies of your resolv.conf on all the
  2055.    systems on any given subnet, not all of which will be servers.
  2056.  
  2057. A: The problem was with older versions of the resolver (4.8.X).  If you
  2058.    listed 127.0.0.1 as the first entry in resolv.conf, and for whatever
  2059.    reason the local name server wasn't running and the resolver fell
  2060.    back to the second name server listed, it would send queries to the
  2061.    name server with the source IP address set to 127.0.0.1 (as it was
  2062.    set when the resolver was trying to send to 127.0.0.1--you use the
  2063.    loopback address to send to the loopback address).
  2064.  
  2065. ------------------------------
  2066.  
  2067. Date: Mon Jan  2 13:50:13 EST 1995
  2068. Subject: Q4.13 - Delegating authority 
  2069.  
  2070. Q: How do I delegate authority for domains within my domain ?
  2071.  
  2072. A: When you start having a very big domain that can be broken into logical 
  2073.    and separate entities that can look after their own DNS information,
  2074.    you will probably want to do this.  Maintain a central area for the
  2075.    things that everyone needs to see and delegate the authority for the
  2076.    other parts of the organization so that they can manage themselves.
  2077.     
  2078.    Another essential piece of information is that every domain that
  2079.    exists must have it NS records associated with it.  These NS records
  2080.    denote the name servers that are queried for information about that
  2081.    zone.  For your zone to be recognized by the outside world, the
  2082.    server responsible for the zone above you must have created a NS
  2083.    record for your machine in your domain.  For example, putting the
  2084.    computer club onto the network and giving them control over their
  2085.    own part of the domain space we have the following.
  2086.    
  2087.    The machine authorative for gu.uwa.edu.au is mackerel and the machine
  2088.    authorative for ucc.gu.uwa.edu.au is marlin.
  2089.     
  2090.    in mackerel's data for gu.uwa.edu.au we have the following
  2091.     
  2092.    @               IN      SOA ...
  2093.                    IN      A       130.95.100.3
  2094.                    IN      MX      mackerel.gu.uwa.edu.au.
  2095.                    IN      MX      uniwa.uwa.edu.au.
  2096.     
  2097.    marlin          IN      A       130.95.100.4
  2098.  
  2099.    ucc             IN      NS      marlin.gu.uwa.edu.au.
  2100.                    IN      NS      mackerel.gu.uwa.edu.au.
  2101.  
  2102.    Marlin is also given an IP in our domain as a convenience.  If they
  2103.    blow up their name serving there is less that can go wrong because
  2104.    people can still see that machine which is a start.  You could place
  2105.    "marlin.ucc" in the first column and leave the machine totally
  2106.    inside the ucc domain as well.
  2107.  
  2108.    The second NS line is because mackerel will be acting as secondary name
  2109.    server for the ucc.gu domain.  Do not include this line if you are not
  2110.    authorative for the information included in the sub-domain.
  2111.  
  2112.  
  2113. ------------------------------
  2114.  
  2115. Date: Wed Mar  1 11:45:00 EST 1995
  2116. Subject: Q4.14 - DNS instead of NIS on a Sun OS 4.1.x system
  2117.  
  2118. Q: I would appreciate any comments on whether running bind 4.9.x will 
  2119.    enable sendmail, ftp, telnet and other TCP/IP services to bypass
  2120.    NIS and connect directly to named.
  2121.  
  2122. A: How to do this is documented quite well in the comp.sys.sun.admin FAQ in
  2123.    questions one and two.  You can get them from:
  2124.  
  2125.       ftp://thor.ece.uc.edu/pub/sun-faq/FAQs/sun-faq.general 
  2126.       http://www.cis.ohio-state.edu/hypertext/faq/usenet/comp-sys-sun-faq
  2127.  
  2128.    as well as from rtfm.mit.edu in the usual place, etc.
  2129.  
  2130.  
  2131. ------------------------------
  2132.  
  2133. Date: Mon Jan  2 13:49:43 EST 1995
  2134. Subject: Q5.1 - No address for root server
  2135.  
  2136.  
  2137. Q: I've been getting the following messages lately from bind-4.9.2..
  2138.         ns_req: no address for root server
  2139.  
  2140. We are behind a firewall and have the following for our named.cache file -
  2141.  
  2142.         ; list of servers
  2143.         .               99999999    IN  NS  POBOX.FOOBAR.COM.
  2144.                         99999999    IN  NS  FOOHOST.FOOBAR.COM.
  2145.         foobar.com.     99999999    IN  NS  pobox.foobar.com.
  2146.  
  2147. A:  You can't do that.  Your nameserver contacts POBOX.FOOBAR.COM, gets the
  2148.     correct list of root servers from it, then tries again and fails
  2149.     because of your firewall.
  2150.  
  2151.     You will need a 'forwarder' definition, to ensure that all requests
  2152.     are forwarded to a host which can penetrate the firewall.  And
  2153.     it is unwise to put phony data into 'named.cache'.
  2154.  
  2155. ------------------------------
  2156.  
  2157. Date: Sun Nov 27 23:32:41 EST 1994
  2158. Subject: Q5.2 - Error - No Root Nameservers for Class XX
  2159.  
  2160. Q: I've received errors before about "No root nameservers for class XX"
  2161.    but they've been because of network connectivity problems.
  2162.    I believe that Class 1 is Internet Class data.
  2163.    And I think I heard someone say that Class 4 is Hesiod??
  2164.    Does anyone know what the various Class numbers are?
  2165.  
  2166. A:  From RFC 1700:
  2167.  
  2168.        DOMAIN NAME SYSTEM PARAMETERS
  2169.        The Internet Domain Naming System (DOMAIN) includes several
  2170.        parameters.  These are documented in [RFC1034] and [RFC1035].  The
  2171.        CLASS parameter is listed here.  The per CLASS parameters are 
  2172.        defined in separate RFCs as indicated.
  2173.  
  2174.        Domain System Parameters:
  2175.  
  2176.        Decimal   Name                                          References
  2177.        --------  ----                                          ----------
  2178.               0  Reserved                                           [PM1]
  2179.               1  Internet (IN)                              [RFC1034,PM1]
  2180.               2  Unassigned                                         [PM1]
  2181.               3  Chaos (CH)                                         [PM1]
  2182.               4  Hesoid (HS)                                       [PM1]
  2183.         5-65534  Unassigned                                         [PM1]
  2184.           65535  Reserved                                           [PM1]
  2185.  
  2186. DNS information for RFC 1700 was taken from
  2187.  
  2188.         ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters
  2189.  
  2190.    Hesiod is class 4, and there are no official root nameservers for class 
  2191.    4, so you can safely declare yourself one if you like.  You might want 
  2192.    to put up a packet filter so that no one outside your network is capable 
  2193.    of making Hesiod queries of your machines, if you define yourself to be 
  2194.    a root nameserver for class 4.
  2195.  
  2196. ------------------------------
  2197.  
  2198. Date: Sun Nov 27 23:32:41 EST 1994
  2199. Subject: Q5.3 - Bind 4.9.x and MX querying?
  2200.  
  2201.  
  2202. Q: If I query a 4.9.x DNS server for MX records, a list of the MX records 
  2203.    as well as a list of the authorative nameservers is returned.  Why ?
  2204.  
  2205. A: Bind 4.9.2 returns the list of nameserver that are authorative
  2206.    for a domain in the response packet, along with their IP
  2207.    addresses in the additional section.
  2208.  
  2209. ------------------------------
  2210.  
  2211. Date: Sun Nov 27 23:32:41 EST 1994
  2212. Subject: Q5.4 - Some root nameservers don't know localhost
  2213.  
  2214. Q: Do I need to define an A record for localhost ?
  2215.  
  2216.    Where is the A record for 127.0.0.1 defined?  I see where
  2217.    the PTR record is defined pointing to localhost, but can't find
  2218.    where the A record is.  And is the A record supposed to be
  2219.    localhost.MY_DOMAIN or just localhost ?
  2220.  
  2221. A: Somewhere deep in the BOG (BIND Operations Guide) that came with
  2222.    4.9.3b9, it says that you define this yourself (if need be) in the 
  2223.    same zone files as your "real" IP addresses for your domain (both 
  2224.    as forward and reverse) and that you should specifically use 
  2225.    "localhost." instead of "localhost.my.dom.ain".
  2226.  
  2227.    The reason for this was that the trailing "." will get stripped when
  2228.    passed back to anyone who asks this question of your nameserver, and 
  2229.    they should then tack on the proper domain name when the go "forward" 
  2230.    from there.  In addition, anyone mis-configured to point to you (and 
  2231.    your domain) from another domain would be putting on their domain 
  2232.    based on this information, and not whatever you might happen to 
  2233.    hand them.
  2234.  
  2235.    Some HP boxen (especially those running HP OpenView) will also need
  2236.    "loopback" defined with this IP address.   You may set it as a CNAME 
  2237.    record pointing to the "localhost." record.
  2238.  
  2239. ------------------------------
  2240.  
  2241. Date: Sun Nov 27 23:32:41 EST 1994
  2242. Subject: Q5.5 - MX records and CNAMES and separate A records for MX targets
  2243.  
  2244. Q: The O'Reilly "DNS and Bind" book warns against using non-canonical
  2245.    names in MX records, however, this warning is given in the context
  2246.    of mail hubs that MX to each other for backup purposes.  I don't see
  2247.    how this applies to mail spokes.  RFC 974 has a similar warning, but
  2248.    I can not see where it specifically prohibits using an alias in an
  2249.    MX record.
  2250.  
  2251. A: Without the restrictions in the RFC, a MTA must request the A records 
  2252.    for every MX listed to determine if it is in the MX list then reduce
  2253.    the list. This introduces many more lookups than would other wise be
  2254.    required. If you are behind a 1200 bps link YOU DON'T WANT TO DO
  2255.    THIS. The addresses associated with CNAMES are not passed as
  2256.    additional data so you will force additional traffic to result even
  2257.    if you are running a caching server locally.
  2258.  
  2259.    There is also the problem of how does the MTA find all of it's
  2260.    IP addresses. This is not straight forward. You have to be able
  2261.    to do this is you allow CNAMEs (or extra A's) as MX targets.
  2262.  
  2263.    The letter of the law is that an MX record should point to an A record.
  2264.        
  2265.    There is no "real" reason to use CNAMEs for MX targets or separate
  2266.    As for nameservers any more. CNAMEs for services other than mail
  2267.    should be used because there is no specified method for locating the
  2268.    desired server yet.
  2269.  
  2270.    People don't care what the names of MX targets are.  They're
  2271.    invisible to the process anyway.  If you have mail for "mary"
  2272.    redirected to "sue" is totally irrelevant.  Having CNAMEs as the
  2273.    targets of MX's just needlessly complicates things, and is more work
  2274.    for the resolver.
  2275.  
  2276.    Having separate A's for nameservers like "ns.your.domain" is
  2277.    pointless too, since again nobody cares what the name of your
  2278.    nameserver is, since that too is invisible to the process.  If you
  2279.    move your nameserver from "mary.your.domain" to "sue.your.domain"
  2280.    nobody need care except you and your parent domain administrator
  2281.    (and the InterNIC).  Even less so for mail servers, since only you
  2282.    are affected.
  2283.  
  2284. Q: Given the example - 
  2285.  
  2286.      hello in cname     realname
  2287.      mailx in mx        0 hello
  2288.  
  2289.    Now, while reading the operating manual of bind it clearly states
  2290.    that this is *not* valid.  These two statements clearly contradict
  2291.    each other.  Is there some later rfc than 974 that overrides what is
  2292.    said in there with respect to MX and CNAMEs?  Anyone have the
  2293.    reference handy?
  2294.  
  2295. A: This isn't what the BOG says at all.  See below.  You can have a CNAME 
  2296.    that points to some other RR type; in fact, all CNAMEs have to point
  2297.    to other names (Canonical ones, hence the C in CNAME).  What you
  2298.    can't have is an MX that points to a CNAME.  MX RR's that point to
  2299.    names which have only CNAME RR's will not work in many cases, and
  2300.    RFC 974 intimates that it's a bad idea:
  2301.  
  2302.       Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
  2303.       a alias and the alias is listed in the MX records for REMOTE.  (E.g.
  2304.       REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
  2305.       can be avoided if aliases are never used in the data section of MX
  2306.       RRs.
  2307.  
  2308.    Here's the relevant BOG snippet:
  2309.  
  2310.          aliases    {ttl}   addr-class   CNAME   Canonical name
  2311.          ucbmonet           IN           CNAME   monet
  2312.  
  2313.          The  Canonical  Name resource record, CNAME, speci-
  2314.          fies an alias or  nickname  for  the  official,  or
  2315.          canonical,  host  name.   This record should be the
  2316.          only one associated with the alias name.  All other
  2317.          resource  records  should  be associated  with the
  2318.          canonical  name,  not  with  the   nickname.  Any
  2319.          resource  records  that  include  a  domain name as
  2320.          their value (e.g., NS or MX) must list the  canoni-
  2321.          cal name, not the nickname.
  2322.  
  2323. ------------------------------
  2324.  
  2325. Date: Wed Mar  1 11:14:10 EST 1995
  2326. Subject: Q5.6 - NS is a CNAME
  2327.  
  2328. Q: Can I do this ?  Is it legal ?
  2329.  
  2330.    @                       SOA     (.........)
  2331.                            NS      ns.host.this.domain.
  2332.                            NS      second.host.another.domain.
  2333.    ns                      CNAME   third
  2334.    third           IN      A       xxx.xxx.xxx.xxx
  2335.  
  2336.  
  2337. A: No.  Only one RR type is allowed to refer, in its data field, to a
  2338.    CNAME, and that's CNAME itself.  So CNAMEs can refer to CNAMEs but 
  2339.    NSs and MXs cannot.
  2340.  
  2341.    BIND 4.9.3 (Beta11 and later) explicitly syslogs this case rather than 
  2342.    simply failing as pre-4.9 servers did.  Here's a current example:
  2343.  
  2344.     Dec  7 00:52:18 gw named[17561]: \
  2345.                    "foobar.com IN NS" points to a CNAME (foobar.foobar.com)
  2346.  
  2347.    Here is the reason why:
  2348.  
  2349.       Nameservers are not required to include CNAME records in the
  2350.       Additional Info section returned after a query.  It's partly an
  2351.       implementation decision and partly a part of the spec.  The
  2352.       algorithm described in RFC 1034 (pp24,25; info also in RFC 1035,
  2353.       section 3.3.11, p 18) says 'Put whatever addresses are available
  2354.       into the additional section, using glue RRs [if necessary]'.
  2355.       Since NS records are speced to contain only primary names of
  2356.       hosts, not CNAMEs, then there's no reason for algorithm to
  2357.       mention them. If, on the other hand, it's decided to allow CNAMEs
  2358.       in NS records (and indeed in other records) then there's no
  2359.       reason that CNAME records might not be included along with A
  2360.       records.  The Additional Info section is intended for any
  2361.       information that might be useful but which isn't strictly the
  2362.       answer to the DNS query processed.  It's an implementation
  2363.       decision in as much as some servers used to follow CNAMEs in 
  2364.       NS references.
  2365.  
  2366.  
  2367. ------------------------------
  2368.  
  2369. Date: Fri Dec  2 16:17:31 EST 1994
  2370. Subject: Q5.7 - Nameserver forgets own A record
  2371.  
  2372.  
  2373. Q: Lately, I've been having trouble with named 4.9.2 and 4.9.3.  
  2374.    Periodically, the nameserver will seem to "forget" its own A record,
  2375.    although the other information stays intact.  One theory I had was
  2376.    that somehow a site that the nameserver was secondary for was
  2377.    "corrupting" the A record somehow.
  2378.  
  2379. A: This is invariably due to not removing ALL of the cached zones
  2380.    when you moved to 4.9.X. Remove ALL cached zones and restart
  2381.    your nameservers.
  2382.  
  2383.    You get "ignoreds" because the primaries for the relevant zones are
  2384.    running old versions of BIND which pass out more glue than is
  2385.    required. named-xfer trims off this extra glue.
  2386.  
  2387. ------------------------------
  2388.  
  2389. Date: Sun Dec  4 22:21:22 EST 1994
  2390. Subject: Q5.8 - General problems (core dumps !)
  2391.  
  2392. Q: I am running bind 4.9.3b9p1 on a DEC alpha OSF/1 V3.0 and have had it 
  2393.    core dump while in debug mode.  The last lines printed to named.run 
  2394.    were [...]
  2395.  
  2396. A: Paul Vixie says:
  2397.  
  2398.    I'm always interested in hearing about cases where BIND dumps core.
  2399.    However, I need a stack trace.   Compile with -g and not -O (unless
  2400.    you are using gcc and know what you are doing) and then when it
  2401.    dumps core, get into dbx or gdb using the executable and the core
  2402.    file and use "bt" to get a stack trace.   Send it to me
  2403.    <paul@vix.com> along with specific circumstances leading to or
  2404.    surrounding the crash (test data, tail of the debug log, tail of the
  2405.    syslog... whatever matters) and ideally you should save your core
  2406.    dump for a day or so in case I have questions you can answer via
  2407.    gdb/dbx.
  2408.  
  2409. ------------------------------
  2410.  
  2411. Date: Mon Jan  2 14:19:22 EST 1995
  2412. Subject: Q5.9 - malloc and DECstations
  2413.  
  2414. We have replaced malloc on our DECstations with a malloc that is more 
  2415. compact in memory usage, and this helped the operation of bind a lot.
  2416. The source is now available for anonymous ftp from
  2417.  
  2418.    ftp://ftp.cs.wisc.edu/pub/misc/malloc.tar.gz
  2419.  
  2420.  
  2421. ------------------------------
  2422.  
  2423. Date: Fri Apr 28 13:56:32 EDT 1995
  2424. Subject: Q6 - Acknowledgements
  2425.  
  2426. Listed in e-mail address alphabetical order, the following people have 
  2427. contributed to this FAQ:
  2428.  
  2429. Benoit.Grange@inria.fr (Benoit.Grange)
  2430. D.T.Shield@csc.liv.ac.uk (Dave Shield)
  2431. adam@comptech.demon.co.uk (Adam Goodfellow)
  2432. andras@is.co.za (Andras Salamon)
  2433. barmar@nic.near.net (Barry Margolin)
  2434. barr@pop.psu.edu (David Barr)
  2435. bj@herbison.com (B.J. Herbison)
  2436. bje@cbr.fidonet.org (Ben Elliston)
  2437. brad@birch.ims.disa.mil (Brad Knowles)
  2438. ckd@kei.com (Christopher Davis)
  2439. cdp@hertz.njit.edu (Chris Peckham)
  2440. cricket@hp.com (Cricket Liu)
  2441. cudep@csv.warwick.ac.uk (Ian 'Vato' Dickinson [ID17])
  2442. dparter@cs.wisc.edu (David Parter)
  2443. e07@nikhef.nl (Eric Wassenaar)
  2444. fwp@CC.MsState.Edu (Frank Peters)
  2445. gah@cco.caltech.edu (Glen A. Herrmannsfeldt) 
  2446. glenn@popco.com (Glenn Fleishman)
  2447. harvey@indyvax.iupui.edu (James Harvey)
  2448. hubert@cac.washington.edu (Steve Hubert)
  2449. jmalcolm@uunet.uu.net (Joseph Malcolm)
  2450. jhawk@panix.com (John Hawkinson)
  2451. kevin@cfc.com (Kevin Darcy)
  2452. lamont@abstractsoft.com (Sean T. Lamont)
  2453. lavondes@tidtest.total.fr (Michel Lavondes)
  2454. mark@ucsalf.ac.uk (Mark Powell)
  2455. marka@syd.dms.CSIRO.AU (Mark Andrews)
  2456. mathias@unicorn.swi.com.sg (Mathias Koerber)
  2457. mjo@iao.ford.com (Mike O'Connor)
  2458. nick@flapjack.ieunet.ie (Nick Hilliard)
  2459. patrick@oes.amdahl.com (Patrick J. Horgan)
  2460. ph10@cus.cam.ac.uk (Philip Hazel)
  2461. rv@seins.Informatik.Uni-Dortmund.DE (Ruediger Volk)
  2462. tanner@george.arc.nasa.gov (Rob Tanner)
  2463. vixie@vix.com (Paul A Vixie)
  2464. wag@swl.msd.ray.com (William Gianopoulos {84718})
  2465. whg@inel.gov (Bill Gray)
  2466. wolf@pasteur.fr (Christophe Wolfhugel)
  2467.  
  2468. Thank you !
  2469.